linux-kernel - Re: [PATCH] Add new open(2) flag

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 26 Apr 2023 08:10:15 -0500
From:   Andrew Walker <awalker@...ystems.com>
To:     David Laight <David.Laight@...lab.com>
Cc:     Ameer Hamza <ahamza@...ystems.com>,
        Christian Brauner <brauner@...nel.org>,
        "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
        "jlayton@...nel.org" <jlayton@...nel.org>,
        "chuck.lever@...cle.com" <chuck.lever@...cle.com>,
        "arnd@...db.de" <arnd@...db.de>,
        "guoren@...nel.org" <guoren@...nel.org>,
        "palmer@...osinc.com" <palmer@...osinc.com>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "slark_xiao@....com" <slark_xiao@....com>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>
Subject: Re: [PATCH] Add new open(2) flag - O_EMPTY_PATH

On Wed, Apr 19, 2023 at 4:29 PM David Laight <David.Laight@...lab.com> wrote:
> ISTM that reopening a file READ_WRITE shouldn't be unconditionally allowed.
> Checking the inode permissions of the file isn't enough to ensure
> that the process is allowed to open it.
> The 'x' (search) permissions on all the parent directories needs to
> be checked (going back as far as some directory the process has open).
>
> If a full pathname is generated this check is done.
> But the proposed O_EMTPY_PATH won't be doing it.
>
> This all matters if a system is using restricted directory
> permissions to block a process from opening files in some
> part of the filesystem, but is also being passed an open
> fd (for reading) in that part of the filesystem.
> I'm sure there are systems that will be doing this.
>
>         David
>

So to be safe, hypothetically, the caller should be required to have
CAP_DAC_READ_SEARCH like with open_by_handle_at(2)?

Andrew