On Wed, Aug 28, 2024 at 05:55:28PM +0200, Jan Kara wrote: > On Wed 28-08-24 15:38:49, Dave Chinner wrote: > > > 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. Yup. The issue that was raised back in ~2008 was to do with rogue machines on the network being able to trivially spoof NFS filehandles to bypass directory access permission checks on the server side. Once the generation numbers are randomised, this sort of attack is easily detected as the ESTALE counter on the server side goes through the roof... > 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... It's always been CAP_SYS_ADMIN for local filehandle interfaces. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
