Re: [PATCH v9 1/8] landlock: Add IOCTL access right

["Günther Noack" <gnoack3000@gmail.com>]

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

--