Date: Mon, 21 Jul 2003 14:46:23 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Ian Dowse <iedowse@maths.tcd.ie> Cc: arch@freebsd.org Subject: Re: *statfs exposure of file system IDs to non-root users Message-ID: <20030721135531.V2911@gamplex.bde.org> In-Reply-To: <200307200306.aa17802@salmon.maths.tcd.ie> References: <200307200306.aa17802@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030721135531.V2911>