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 --
