Duplicate SMB file_ids leading to Windows client cache poisoning
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,
> > 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.
> 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.
More information about the samba-technical