Duplicate SMB file_ids leading to Windows client cache poisoning

Christof Schmitt cs at samba.org
Fri Dec 10 21:20:51 UTC 2021


On Fri, Dec 10, 2021 at 03:37:57PM -0500, Andrew Walker via samba-technical wrote:
> On Fri, Dec 10, 2021 at 2:08 PM Christof Schmitt <cs at samba.org> 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).
> >
> 
> Are we sure about that? For the fun of it, I just rewrote how we were
> allocating file_ids so that they were derived from smb_fname->base_name.
> 
> ```
> Andrews-MacBook-Pro:share2 awalker$ cat testfile
> CCC
> Andrews-MacBook-Pro:share2 awalker$ cat testfile2
> BBB
> Andrews-MacBook-Pro:share2 awalker$ stat testfile2
> 872415469 3840159432845878725 -rwxr--r-- 1 awalker staff 0 4 "Dec 10
> 15:24:36 2021" "Dec 10 15:27:17 2021" "Dec 10 15:27:17 2021" "Dec 10
> 15:24:36 2021" 1024 2 0 testfile2
> Andrews-MacBook-Pro:share2 awalker$ stat testfile
> 872415469 398 -rw-r--r-- 1 awalker staff 0 4 "Dec 10 15:27:56 2021" "Dec 10
> 15:27:56 2021" "Dec 10 15:27:56 2021" "Dec 10 15:27:56 2021" 1024 2 0x10000
> testfile
> Andrews-MacBook-Pro:share2 awalker$ cat testfile2
> CCC
> Andrews-MacBook-Pro:share2 awalker$ cat testfile
> BBB
> Andrews-MacBook-Pro:share2 awalker$ stat testfile2
> 872415469 3840159432845878725 -rw-r--r-- 1 awalker staff 0 4 "Dec 10
> 15:28:46 2021" "Dec 10 15:29:30 2021" "Dec 10 15:29:30 2021" "Dec 10
> 15:28:46 2021" 1024 2 0 testfile2
> Andrews-MacBook-Pro:share2 awalker$ stat testfile
> 872415469 6066312061719206029 -rwxr--r-- 1 awalker staff 0 4 "Dec 10
> 15:24:36 2021" "Dec 10 15:27:17 2021" "Dec 10 15:27:17 2021" "Dec 10
> 15:24:36 2021" 1024 2 0 testfile
> Andrews-MacBook-Pro:share2 awalker$
> ```
> 
> Behind the scenes on my Samba server I renamed the files. Inodes stayed the
> same when viewed from MacOS client, but file contents changed. This was in
> Big Sur though. Or is this application-specific?

I tested this two years ago, and could demonstrate the problem.

Christof



More information about the samba-technical mailing list