Re: [RFC PATCH] fs: obtain the inode generation number from vfs directly

["Darrick J. Wong" <djwong@kernel.org>]

On Wed, Aug 28, 2024 at 05:55:28PM +0200, Jan Kara wrote:
> On Wed 28-08-24 15:38:49, Dave Chinner wrote:
> > On Tue, Aug 27, 2024 at 10:11:48AM -0700, Darrick J. Wong wrote:
> > > On Tue, Aug 27, 2024 at 11:22:17AM +0200, Christian Brauner wrote:
> > > > On Mon, Aug 26, 2024 at 10:37:12PM GMT, Darrick J. Wong wrote:
> > > > > On Tue, Aug 27, 2024 at 10:32:38AM +0800, Hongbo Li wrote:
> > > > > > 
> > > > > > 
> > > > > > On 2024/8/27 10:13, Darrick J. Wong wrote:
> > > > > > > On Tue, Aug 27, 2024 at 01:41:08AM +0000, Hongbo Li wrote:
> > > > > > > > Many mainstream file systems already support the GETVERSION ioctl,
> > > > > > > > and their implementations are completely the same, essentially
> > > > > > > > just obtain the value of i_generation. We think this ioctl can be
> > > > > > > > implemented at the VFS layer, so the file systems do not need to
> > > > > > > > implement it individually.
> > > > > > > 
> > > > > > > What if a filesystem never touches i_generation?  Is it ok to advertise
> > > > > > > a generation number of zero when that's really meaningless?  Or should
> > > > > > > we gate the generic ioctl on (say) whether or not the fs implements file
> > > > > > > handles and/or supports nfs?
> > > > > > 
> > > > > > This ioctl mainly returns the i_generation, and whether it has meaning is up
> > > > > > to the specific file system. Some tools will invoke IOC_GETVERSION, such as
> > > > > > `lsattr -v`(but if it's lattr, it won't), but users may not necessarily
> > > > > > actually use this value.
> > > > > 
> > > > > That's not how that works.  If the kernel starts exporting a datum,
> > > > > people will start using it, and then the expectation that it will
> > > > > *continue* to work becomes ingrained in the userspace ABI forever.
> > > > > Be careful about establishing new behaviors for vfat.
> > > > 
> > > > Is the meaning even the same across all filesystems? And what is the
> > > > meaning of this anyway? Is this described/defined for userspace
> > > > anywhere?
> > > 
> > > AFAICT there's no manpage so I guess we could return getrandom32() if we
> > > wanted to. ;)
> > > 
> > > But in seriousness, the usual four filesystems return i_generation.
> > 
> > We do? 
> > 
> > I thought we didn't expose it except via bulkstat (which requires
> > CAP_SYS_ADMIN in the initns).
> > 
> > /me goes looking
> > 
> > Ugh. Well, there you go. I've been living a lie for 20 years.
> > 
> > > That is changed every time an inumber gets reused so that anyone with an
> > > old file handle cannot accidentally open the wrong file.  In theory one
> > > could use GETVERSION to construct file handles
> > 
> > Not theory. We've been constructing XFS filehandles in -privileged-
> > userspace applications since the late 90s. Both DMAPI applications
> > (HSMs) and xfsdump do this in combination with bulkstat to retreive
> > the generation to enable full filesystem access without directory
> > traversal being necessary.
> > 
> > I was completely unaware that FS_IOC_GETVERSION was implemented by
> > XFS and so this information is available to unprivileged users...
> > 
> > > (if you do, UHLHAND!)
> > Not familiar with that acronym.

U Have Lost, Have A Nice Day!

> > 
> > > instead of using name_to_handle_at, which is why it's dangerous to
> > > implement GETVERSION for everyone without checking if i_generation makes
> > > sense.
> > 
> > Yup. If you have predictable generation numbers then it's trivial to
> > guess filehandles once you know the inode number. Exposing
> > generation numbers to unprivileged users allows them to determine if
> > the generation numbers are predictable. Determining patterns is
> > often as simple as a loop doing open(create); get inode number +
> > generation; unlink().
> 
> As far as VFS goes, we have always assumed that a valid file handles can be
> easily forged by unpriviledged userspace and hence all syscalls taking file
> handle are gated by CAP_DAC_READ_SEARCH capability check. That means
> userspace can indeed create a valid file handle but unless the process has
> sufficient priviledges to crawl the whole filesystem, VFS will not allow it
> to do anything special with it.
> 
> I don't know what XFS interfaces use file handles and what are the
> permission requirements there but effectively relying on a 32-bit cookie
> value for security seems like a rather weak security these days to me...

CAP_SYS_ADMIN.

--D

> 								Honza
> -- 
> Jan Kara <jack@suse.com>
> SUSE Labs, CR
>