Duplicate SMB file_ids leading to Windows client cache poisoning

[Andrew Walker]

On Mon, Dec 13, 2021 at 3:23 PM Andrew Walker <awalker at ixsystems.com> wrote:

>
>
> On Fri, Dec 10, 2021 at 4:53 PM Andrew Walker <awalker at ixsystems.com>
> wrote:
>
>>
>>
>> On Fri, Dec 10, 2021 at 4:37 PM Tom Talpey <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
> ```
> 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
>

Okay. ZFS on Linux doesn't present inode generation via FS_IOC_GETVERSION.
We've opened a PR against openzfs to add it.
To summarize the current status of using inode generation on ZFS: it
doesn't work properly on FreeBSD and Linux.

FreeBSD fix: https://github.com/openzfs/zfs/pull/12851
Linux fix: https://github.com/openzfs/zfs/pull/12856

I hope this helps somewhat for making decisions. FreeBSD case is
particularly painful.