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
