Duplicate SMB file_ids leading to Windows client cache poisoning

Tom Talpey tom at talpey.com
Tue Dec 14 17:36:15 UTC 2021

On 12/13/2021 3:23 PM, Andrew Walker wrote:
> On Fri, Dec 10, 2021 at 4:53 PM Andrew Walker <awalker at ixsystems.com 
> <mailto:awalker at ixsystems.com>> wrote:
>     On Fri, Dec 10, 2021 at 4:37 PM Tom Talpey <tom at talpey.com
>     <mailto:tom at talpey.com>> wrote:
>         On 12/10/2021 4:23 PM, Christof Schmitt wrote:
>          > On Fri, Dec 10, 2021 at 04:04:09PM -0500, Tom Talpey via
>         samba-technical wrote:
>          >> I believe the EXT, BTRFS, XFS and a few other Linux
>         filesystems support
>          >> retrieving the generation number via
>         ioctl(FS_IOC_GETVERSION). 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.
>          >
>          > I missed FS_IOC_GETVERSION. That might be an option, since
>         that is at
>          > least supported on the most commonly used file systems (ext4,
>         xfs,
>          > btrfs). And if the call fails, we could log a warning, that
>         this setup
>          > might be unreliable for MacOS clients.
>         Looks like ZFS has its own idea, ZFS_IOC_OBJ_TO_STATS. But we could
>         cover the basics with a handful of tries.
>         What about packing the dev_t, ino_t and generation number all into
>         64 bits, without risking a collision? I think the dev_t is needed
>         unless the Samba server can guarantee the share always maps to
>         exactly the same one, which seems problematic.
>         Tom.
>     With ZFS it looks like st_gen gets populated with the znode sequence
>     number, which may increment unexpectedly for our purposes (for
>     instance when timestamps incremented). I'll double-check with our
>     ZFS devs tomorrow. 
> To clarify on this, FreeBSD return inode generation in stat(2) output. 
> stat.st_gen. In the case of ZFS on FreeBSD though, this value increments 
> on every file change. You can view by running

Oddly, I don't see st_gen in any online FreeBSD manpage. Totally
agree that it's useless to bump it on any file change. How wide
is the field? Historically, generation numbers were small, 8-16b.

But I do see that FreeBSD does provide an st_birthtim. That seems
like a better option, if populated?


> ```
> stat -f %v file
> touch file
> stat -f %v file
> ```
> This is a bug and am introducing a patch to basically populate that 
> datum with the id of the transaction group in which the znode was 
> created (which means that combination of st_gen and st_ino should be 
> unique for filesystem). Unfortunately, this means that at least on 
> FreeBSD the behavior will be unpredictable depending on the version of 
> FreeBSD (or ZFS if openzfs from ports is being used for some reason). 
> I'll check the behavior of ZFS on Linux later today or perhaps tomorrow.
> tmpfs, ffs, and a few other BSD filesystems randomize inode generation 
> on file creation, which seems like it should be fine for our purposes.
> Andrew

More information about the samba-technical mailing list