Date: Tue, 3 Apr 2001 14:42:10 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Matt Dillon <dillon@earth.backplane.com> Cc: Robert Watson <rwatson@FreeBSD.ORG>, freebsd-arch@FreeBSD.ORG Subject: Re: Eliminate crget() from nfs kernel code? Message-ID: <20010403144210.B12164@fw.wintelcom.net> In-Reply-To: <200104032129.f33LTmj70619@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Apr 03, 2001 at 02:29:48PM -0700 References: <Pine.NEB.3.96L.1010403164943.7478F-100000@fledge.watson.org> <200104032129.f33LTmj70619@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Matt Dillon <dillon@earth.backplane.com> [010403 14:30] wrote: > :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. Hmm, strange there's not a static cred available for these usages. What about using process 0's ucred, does it even have one? I'm sure there's other examples of how to do this correctly in the code. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Represent yourself, show up at BABUG http://www.babug.org/ 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?20010403144210.B12164>