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

[Jan Kara]

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

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