RE: [PATCH] Add new open(2) flag - O_EMPTY_PATH

[David Laight]

From: Ameer Hamza
> Sent: 19 April 2023 02:15
> 
> On Fri, Jan 06, 2023 at 02:06:51PM +0100, Christian Brauner wrote:
> > On Wed, Dec 28, 2022 at 09:02:49PM +0500, Ameer Hamza wrote:
> > > This patch adds a new flag O_EMPTY_PATH that allows openat and open
> > > system calls to open a file referenced by fd if the path is empty,
> > > and it is very similar to the FreeBSD O_EMPTY_PATH flag. This can be
> > > beneficial in some cases since it would avoid having to grant /proc
> > > access to things like samba containers for reopening files to change
> > > flags in a race-free way.
> > >
> > > Signed-off-by: Ameer Hamza <ahamza@xxxxxxxxxxxxx>
> > > ---
> >
> > In general this isn't a bad idea and Aleksa and I proposed this as part
> > of the openat2() patchset (see [1]).
> >
> > However, the reason we didn't do this right away was that we concluded
> > that it shouldn't be simply adding a flag. Reopening file descriptors
> > through procfs is indeed very useful and is often required. But it's
> > also been an endless source of subtle bugs and security holes as it
> > allows reopening file descriptors with more permissions than the
> > original file descriptor had.
> >
> > The same lax behavior should not be encoded into O_EMPTYPATH. Ideally we
> > would teach O_EMPTYPATH to adhere to magic link modes by default. This
> > would be tied to the idea of upgrade mask in openat2() (cf. [2]). They
> > allow a caller to specify the permissions that a file descriptor may be
> > reopened with at the time the fd is opened.
> >
> > [1]: https://lore.kernel.org/lkml/20190930183316.10190-4-cyphar@xxxxxxxxxx/
> > [2]: https://lore.kernel.org/all/20220526130355.fo6gzbst455fxywy@senku/Kk
> 
> Thank you for the detailed explanation and sorry for getting back late
> at it. It seems like a pre-requisite for O_EMPTYPATH is to make it safe
> and that depends on a patchset that Aleksa was working on. It would be
> helpful to know the current status of that effort and if we could expect
> it in the near future.

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

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)