Duplicate SMB file_ids leading to Windows client cache poisoning

Andrew Walker awalker at ixsystems.com
Fri Dec 10 20:37:57 UTC 2021


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?


More information about the samba-technical mailing list