*statfs exposure of file system IDs to non-root users

Bruce Evans bde at zeta.org.au
Sun Jul 20 21:46:42 PDT 2003


On Sun, 20 Jul 2003, Ian Dowse wrote:

> In changing umount(8) to use statfs(2), I just noticed that the
> various *statfs calls hide the filesystem IDs from non-root users:
>
> 	if (suser(td)) {
> 		bcopy(sp, &sb, sizeof(sb));
> 		sb.f_fsid.val[0] = sb.f_fsid.val[1] = 0;
> 		sp = &sb;
> 	}
>
> This was added in vfs_syscalls.c revision 1.61 (March 1997) and
> came from OpenBSD. I guess the reason was to hide information that
> gets used in NFS filehandles, but it doesn't do us any good now as
> you can get the real IDs from getfsstat() as a normal user.

This seems to be a bug in the import from OpenBSD.  OpenBSD changed
statfs() and getfsstat() in the same commit (rev.1.22 13-Feb-1997 in
this file) to not expose f_fsid to non-root.

> Being
> able to get and compare file system IDs is useful for umount, and
> umount can be used by non-root users when vfs.usermount is set.

> Is there a good reason not to delete this fsid hiding? I guess if

I never really understood hiding f_fsid for the mount point.  In any
case, it never actually worked for FreeBSD and doesn't seemed to have
been adopted by NetBSD.

> we do want to keep the values used in NFS handles secret while still
> exposing useful IDs to userland, we could add a separate user-side
> fsid to struct mount and use that instead. The IDs for NFS need to
> be persistent across reboots, but the user ones don't. Note that
> NFS filesystems use a hidden generation number for each file too,
> so just knowing the filesystem ID isn't enough on its own to form
> a valid handle.

We expose part of the vfsid for at least nfs mountpoints via fake
(st_dev) device numbers for stat().  See getnewfsid().  The exposed
part is a sort of hopefully-unique hash of the fsid.  umount could
use something similar -- a guaranteed-unique unreversable hash of
the fsid -- instead of the fsid if the fsid is considered too
sensitive to expose.  Guaranteed uniqueness in a snall number of
bits (16) wouldn't hurt for getnewfsid() generally, but getnewfsid()
has the additional reqirement of giving fairly persistent ids.

Bruce


More information about the freebsd-arch mailing list