Duplicate SMB file_ids leading to Windows client cache poisoning

[Andrew Walker]

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