Date: Mon, 12 Nov 2001 05:47:24 -0500 (EST)
From: Robert Watson <rwatson@FreeBSD.ORG>
To: Kirk McKusick <mckusick@mckusick.com>
Cc: freebsd-arch@FreeBSD.ORG
Subject: Re: cur{thread/proc}, or not.
Message-ID: <Pine.NEB.3.96L.1011112054158.16646E-100000@fledge.watson.org>
In-Reply-To: <200111111815.fABIFG336949@beastie.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 11 Nov 2001, Kirk McKusick wrote: > Some many years ago, I tried to get rid of all the references to curproc > in the filesystem code, and quickly came to the realization that it > would require adding a proc pointer to virtually every subroutine in the > filesystem code. For the reasons that you have noted, this is ugly and > adds bloat to the stack space. On the other hand, there are places where > the filesystem code does not want to use the current process credential. > One of the more evident ones is in the NFS server code which wants to > pass down the credential of the requesting client rather than its own. > Solaris uses a very ugly hack where the server thread replaces its > credential with that of its client, does the VOP call, then puts its own > credential back when it returns. This sort of problem could exist in > almost any instance where the kernel is acting as a server. So, > completely removing process/credential references from the kernel > interfaces is not the right solution either. Right now, many of the VFS calls pass a credential in, which is used in lieu of the process credential in most cases. The prominent exceptions to this rule seem to be in the device code (where process credentials are used), and in the smattering of VOP calls where in UFS/FFS, an authorization decision is not required. By putting the credential into these calls, I think most NFS cases could be normalized. This would be consistent with the approach adopted by several other systems I looked at, and seems like it may intuitively be the right approach given the 'file' cached credential model. As Peter has pointed out, this change could be independent of any choice about curproc/curthread, and is probably worth doing regardless of the choice there. Probably the right 'approach' here is to assume that operations on 'vnode' require a 'ucred', whereas operations on 'file' generally do 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.1011112054158.16646E-100000>