[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAB5c7xquuk7-kWZBY7fVmKiGh0_YxR=UhLjMUpdTx=2rF+PuzA@mail.gmail.com>
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
Powered by blists - more mailing lists