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@xxxxxxxx> SUSE Labs, CR
