[PATCH v9 1/8] landlock: Add IOCTL access right
Günther Noack
gnoack3000 at gmail.com
Mon Feb 19 21:44:13 UTC 2024
Hello!
On Sun, Feb 18, 2024 at 09:34:39AM +0100, Günther Noack wrote:
> 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?
FYI, I figured it out —
- every call to open(2) results in a new struct file
- the resulting struct file refers to an existing inode
- this is not supported for all inode types;
a rough categorization happens in inode.c:init_special_inode()
The open(2) syscall creates a struct file and populates it
based on the origin fd's underlying inode through the .open function
in file_operations.
The procfs implementation for the lookup is in proc_pid_get_link /
proc_fd_link on the proc side. It patches up the current task's
nameidata struct as a side effect by calling nd_jump_link().
For reference, I described this it in more detail at
https://blog.gnoack.org/post/proc-fd-is-not-dup/.
—Günther
--
More information about the Linux-security-module-archive
mailing list