Date: Tue, 3 Apr 2001 23:04:02 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Matt Dillon <dillon@earth.backplane.com> Cc: Alfred Perlstein <bright@wintelcom.net>, Brian Somers <brian@Awfulhak.org>, freebsd-arch@FreeBSD.ORG Subject: Re: Eliminate crget() from nfs kernel code? Message-ID: <Pine.NEB.3.96L.1010403225735.7479E-100000@fledge.watson.org> In-Reply-To: <200104032335.f33NZWK73052@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 3 Apr 2001, Matt Dillon wrote: > :> > 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 ? > : > :Yes, it most likely would. However, it still strikes me a bit as though this is a, ``Help, I need a credential, someone find a credential'' as opposed to a, ``What credential is the one we want to use here.'' My temptation here would be to try temporarily switching to using p->p_ucred for the time being, and as Matt indicated, watch closely for reports of any interoperability problems with other implementations. Right now, the code selects to make the call using all available privilege: in a more contained environment, that might no longer be appropriate. Particularly if the ucred contains MAC integrity and confidentiality labels, which translate into labeling of the packet itself, or map into use of IPsec SAs or the like. How about I put together a patch, interop against the implementations I have on-hand (various FreeBSD, Linux, Solaris versions) and see if I'm shooting myself in the foot or not... Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services 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?Pine.NEB.3.96L.1010403225735.7479E-100000>