Date: Tue, 03 Apr 2001 23:54:50 +0100 From: Brian Somers <brian@Awfulhak.org> To: Alfred Perlstein <bright@wintelcom.net> Cc: Matt Dillon <dillon@earth.backplane.com>, Robert Watson <rwatson@FreeBSD.ORG>, freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: Eliminate crget() from nfs kernel code? Message-ID: <200104032254.f33Mso560006@hak.lan.Awfulhak.org> In-Reply-To: Message from Alfred Perlstein <bright@wintelcom.net> of "Tue, 03 Apr 2001 14:42:10 PDT." <20010403144210.B12164@fw.wintelcom.net>
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. Solaris has a ``kcred'' global - wrapped with a CRED() macro AFAIR. Maybe that'd be useful here ? > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > Represent yourself, show up at BABUG http://www.babug.org/ -- Brian <brian@Awfulhak.org> <brian@[uk.]FreeBSD.org> <http://www.Awfulhak.org>; <brian@[uk.]OpenBSD.org> Don't _EVER_ lose your sense of humour ! 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?200104032254.f33Mso560006>