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. The repo[1] that was mentioned here[2] seems to be private. I am wondering if there's a way to look at the patch somehow. [1]: https://github.com/cyphar/linux/tree/magiclink/main [2]: https://lore.kernel.org/all/20220526130952.z5efngrnh7xtli32@senku/
