Duplicate SMB file_ids leading to Windows client cache poisoning

[Tom Talpey]

On 12/10/2021 2:08 PM, Christof Schmitt wrote:
> On Fri, Dec 10, 2021 at 09:57:07AM -0800, Jeremy Allison via samba-technical wrote:
>> On Fri, Dec 10, 2021 at 06:06:56PM +0100, Ralph Boehme via samba-technical wrote:
>>> On 12/10/21 17:56, Andrew Walker wrote:
>>>> That's a good point, but if MacOS SMB client is faking up an inode
>>>> number based on a hash of the filename in the zero-id case, isn't it
>>>> even more likely to yield a collision at some point?
>>>
>>> well, it's somehash(name) combined with the parent-inode number. I know,
>>> it's not ideal.
>>>
>>> But going back to inode numbers brings us back to:
>>>
>>> https://bugzilla.samba.org/show_bug.cgi?id=12715
>>>
>>> *scratches head*
>>
>> OK, seems to me that we need inode numbers by default,
>> as that's what works with both Windows an Linux clients.
>>
>> If Mac's need special handling here, then we have the
>> capability to detect them and switch out the inode
>> numbers for Mac clients (fruit... :-) :-).
> 
> Not every Samba server where Mac clients connect has vfs_fruit enabled.
> And requiring vfs_fruit to prevent data corruption seems like a big
> step. The requirement for Mac clients is the same, no matter whether
> the fileid is generated in vfs_default or vfs_fruit.
> 
> The initial problem is fairly easy to recreate: Use a Samba version that
> reports inode numbers as file ids, create 100 different files with
> different data from MacOS. Now go to the file system, delete those files
> and create files with the same name and different data. Then read those
> files on the Mac client. Chances are that the Mac client will now show
> the data from the old files (due to the fileid based caching. If a new
> file got the same inode, it has the same fileid).
> 
> 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. 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). 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.

> For additional fun, the spec says:
> 
>      2.1.9 64-bit file ID
> ...
>     The identifier SHOULD<10> be unique to the volume and stable until the
>     file is deleted.
> ...

Yeah, that SHOULD is confusing (and technically a doc bug). It is not
making any reliable normative statement. We could toss that to dochelp.

> So technically the Mac is wrong to expect identifiers to be unique
> across file deletions. I assume this comes from the old MacOS file
> systems that have a CNID that is only increasing.
> 
> I am not sure how to solve this for the general case...

I think the exception for deletion is stemming from the possibility of
oplocks or leases, which will provide a callback that the client will
use to flush its cache. But these are optional, and aren't completely
reliable, in the face of network partitioning. It gets particularly
messy when the server supports durable, resilient or persistent handles.

Ralph, did you try returning FFFF instead of zero for the DiskFileId in
vfs_fruit? As in, cannot be provided for just that file? Perhaps MacOS
does something different in that case.

Sorry, no brilliant nuggets of wisdom from me at this point either.

Tom.