FUSE statfs f_fsid field

FUSE statfs f_fsid field

[Jeff Layton]

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?

[1]: https://tracker.ceph.com/issues/53045
-- 
Jeff Layton <jlayton@kernel.org>

Re: FUSE statfs f_fsid field

[Miklos Szeredi]

On Thu, 4 Nov 2021 at 14:27, Jeff Layton <jlayton@kernel.org> 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

Re: FUSE statfs f_fsid field

[Jeff Layton]

On Thu, 2021-11-04 at 14:50 +0100, Miklos Szeredi wrote:
> On Thu, 4 Nov 2021 at 14:27, Jeff Layton <jlayton@kernel.org> 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.

Cheers,
-- 
Jeff Layton <jlayton@kernel.org>

RE: FUSE statfs f_fsid field

[Frank Filz]

> On Thu, 2021-11-04 at 14:50 +0100, Miklos Szeredi wrote:
> > On Thu, 4 Nov 2021 at 14:27, Jeff Layton <jlayton@kernel.org> 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