[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