> On Thu, 2021-11-04 at 14:50 +0100, Miklos Szeredi wrote: > > On Thu, 4 Nov 2021 at 14:27, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > > > > > Hi Miklos! > > > > > > I was looking at an issue [1] with ceph-fuse and noticed that statfs > > > always reports f_fsid == 0 via statfs. Is there a reason for not > > > letting the driver fill out that field? > > > > Hi Jeff, > > > > I do not remember ever hearing of this field. The statfs(2) man page > > doesn't make it very obvious either: > > > > The f_fsid field > > > > [...] The general idea is that f_fsid contains some random > > stuff such that > > the pair (f_fsid,ino) uniquely determines a file. Some operating sys‐ > > tems use (a variation on) the device number, or the device number com‐ > > bined with the filesystem type. [...] > > > > I'd be somewhat concerned about allowing an unprivileged fuse server > > to fill this, as that may allow impersonation of another filesystem. > > > > For a privileged fuse server I see no problem with allowing to set this. > > Thanks, Miklos, > > Good point about impersonation. I'll have to think about whether it's worthwhile > to change this for privileged servers. I'm not sure what all uses f_fsid. I know nfs-ganesha uses it (but we have a way around it so long as the file system either has a UUID available via blkid or has a unique device id (actually, we require all file systems to have unique device id at the moment...). The find tool and similar tools may use it in their loop detection where they stop traversing into a file system if they see duplicate fsid/inode number pairs (not sure if they use other mechanisms to distinguish file systems). Impersonating another file system would obviously cause problems with those uses of fsid. Other than a DOS though, I'm not sure what else they could do and there is some administrator control over mounted file systems. This always being 0 for FUSE file systems would definitely be a hiccup to nfs-ganesha using FUSE file systems, though that's not something we have put any effort into testing... Frank
