Duplicate SMB file_ids leading to Windows client cache poisoning

[J. Bruce Fields]

On Fri, Dec 10, 2021 at 04:04:09PM -0500, Tom Talpey via samba-technical wrote:
> On 12/10/2021 2:08 PM, Christof Schmitt wrote:
> >As this thread shows, timestamps are not a universal solution.
> >In vfs_gpfs, we are able to retrieve the inode number and the inode
> >generation and use that to generate unique ids. That seems to work
> >reasonably well. But even the standard Linux statx() call does not
> >return the generation number.

I wonder why not?  Maybe it could be added.

> So that would only be solution for file
> >systems that that provide an interface to query the generation number.
> 
> I believe the EXT, BTRFS, XFS and a few other Linux filesystems support
> retrieving the generation number via ioctl(FS_IOC_GETVERSION).

There's also name_to_handle_at() to get a filehandle, I don't know if
that's useful for your purposes.  (It can be tens of bytes long, so
you'd have to hash it and do some back-of-the-envelope calculations on
collision probabilities for the typical client cache sizes.)

> But I'm
> not certain how universal this is. There being hundreds of file systems
> in Linux...
> 
> Could Samba perhaps insert a kernel module, or use the SMB client kmod,
> to fetch this? It'd be ugly and will have security implications, so I
> would not go into it lightly.

Even if you could: it's true that there's an i_generation in the generic
struct inode, but I doubt there's any guarantee it meets your
requirements (or is even initialized to anything at all) for a given
filesystem.

(Whereas if it were added to statx then the filesystem could choose to
return it or not depending on whether it's supported.)

--b.