Date: Tue, 3 Apr 2001 14:29:48 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Eliminate crget() from nfs kernel code? Message-ID: <200104032129.f33LTmj70619@earth.backplane.com> References: <Pine.NEB.3.96L.1010403164943.7478F-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:While extending ucred in a rewrite of my mandatory access control
:implementation on FreeBSD, I managed to panic the system:
:
:...
:
:What I discovered was that the nfs_statfs() implementation fakes up a
:credential using crget() to use when invoking nfs_fsinfo(), and uses it
:only for the lifetime of the nfs_statfs() call. While I don't claim to
:have a complete understanding of the NFS code, it appears that this is
:done in lieu of using p->p_ucred, and that other related VFS calls are
:passed a ucred as an argument. This causes some problems for
:implementations of extensions to ucred, as it introduces a new (and fairly
:arbitrary) credential that must be created to satisfy the need to call
:crget() here. I was wondering if someone could expound on the rationale
:for creating a new (and fairly poorly initialized) ucred in this scenario,
:and perhaps comment also on two possible work-arounds:
:
: 1) Use p->p_ucred.
: 2) Introduce a ucred argument to vfs_statfs() to be used by
: file system implementations that require it.
:...
:ucred argument (although this will break binary compatibility in -CURRENT,
:which is where I'd consider doing the change). The effect of the current
:code, btw, is to always make NFSPROC_STATFS() calls using uid/gid of 0
:(possibly mapped to nobody on the server), rather than the calling process
:-- it's possible to imagine environments in which this is inappropriate,
:especially with the introduction of MAC. I notice that there's some
:similar behavior in the ncp code.
:
:Robert N M Watson FreeBSD Core Team, TrustedBSD Project
:robert@fledge.watson.org NAI Labs, Safeport Network Services
Hmm. It's hard to say. The standard doesn't say anything about
the credential needing to be root/wheel over the wire for statfs(),
but if we change it we will probably break someone somewhere.
I think you want to keep crget()/crfree() if possible, just so you
don't have to worry about the data being sent over the wire breaking
some poor sod. But if you want to bite the bullet and use the process
ucred I'd say go for it - keep a careful watch for complaints of
FreeBSD suddenly failing against various NFS servers though.
The fake ucred has been in the NFS codebase from day 1. It could very
well be outdated now.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104032129.f33LTmj70619>