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

[Gordon Tetlow]

On Sun, Jul 20, 2003 at 03:06:13AM +0100, 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. 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
> 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.

But it's that much less that an attacker needs to guess. Can you make
it so a non-root user falls back to the old umount method, thereby
not needing the fsid? I think if you have a hung remote NFS server,
root probably needs to step in to check on things.

-gordon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20030720/61be55bd/attachment.bin