[PATCH v9 1/8] landlock: Add IOCTL access right
Günther Noack
gnoack3000 at gmail.com
Sun Feb 18 08:34:39 UTC 2024
On Fri, Feb 16, 2024 at 04:51:40PM +0100, Mickaël Salaün wrote:
> On Fri, Feb 16, 2024 at 03:11:18PM +0100, Mickaël Salaün wrote:
> > What about /proc/*/fd/* ? We can test with open_proc_fd() to make sure
> > our assumptions are correct.
>
> Actually, these fifo and socket checks (and related optimizations)
> should already be handled with is_nouser_or_private() called by
> is_access_to_paths_allowed(). Some new dedicated tests should help
> though.
I am generally a bit confused about how opening /proc/*/fd/* works.
Specifically:
* Do we have to worry about the scenario where the file_open hook gets
called with the same struct file* twice (overwriting the access
rights)?
* I had trouble finding the place in fs/proc/ where the re-opening is
implemented.
Do you happen to understand this in more detail? At what point do the
re-opened files start sharing the same kernel objects? Is that at the
inode level?
The documentation I consulted unfortunately did not explain it either:
* The man page (proc_pid_fd(5), or previously proc(5)) does not
discuss the behavior on open() much, apart from using it in some
examples.
* Michael Kerrisk's "Linux Programming Interface" book claims that the
behaviour of opening /dev/fd/1 is like doing dup(1) (section 5.11)
-- that is true on other UNIXes, but on Linux the resulting file
descriptors do not share the same struct file* apparently. This
makes a difference for regular files, where the two FDs subsequently
use two separate offsets into the file (f_pos).
Thanks,
–Günther
More information about the Linux-security-module-archive
mailing list