From owner-freebsd-arch Mon Apr 9 16: 0:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 4AA4437B423; Mon, 9 Apr 2001 16:00:26 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f39MxEG32038; Mon, 9 Apr 2001 15:59:14 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200104092244.PAA02241@usr08.primenet.com> Date: Mon, 09 Apr 2001 15:59:49 -0700 (PDT) From: John Baldwin To: Terry Lambert Subject: Re: Eliminate crget() from nfs kernel code? Cc: ((Robert Watson)) Cc: ((Robert Watson)) , ((Matt Dillon)) , freebsd-arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 09-Apr-01 Terry Lambert wrote: >> >> make the NFS RPC with an existing credential >> > >> > instantiate a credential >> > make the NFS RPC >> > >> > >> > >> > free the credential >> > >> >> into the implementation, and it is valid for the durection of the >> >> function >> >> call. If the NFS implementation needs to preserve the credential, it >> >> will >> >> do so by bumping the reference count. >> > >> > It was not clear to me from a casual perusal of the code whether >> > or not holding a reference to a credential used by a process would >> > keep it from going away, or if it always went away on the 1->0 >> > decrement. >> >> Geez, that must've been _real_ casual, Terry. :) > > Maybe I was too opaque in my statement? > > By "reference", I did not mean an increment of cr_ref. Well, I'm not sure how else one holds a reference, but ok. > Looking at the code less casually, it seems to always go away on the > 1->0 decrement. Yes. > I can imagine cases where the NFS reference becomes the only > remaining reference for the credential. > > I think that that is a Bad Thing, since NFS outages can live > drastically longer than the referencing process that gave it > the credential. > > I can imagine a bunch of orphan credentials piling up in the > NFS code, waiting for the RPC to come back from a dead server. Ok, however, with the current crget() code, we would have even more of these lying around. At least by using p->p_ucred, processes that share the same ucred will use the same ucred's in NFS. The proposed change will result in _fewer_ credentials piling up in this case than just creating a new ucred for each call. > My complaint was that there is not a 1:1 correspondance between > credentials and sessions (or all my processes would point to the > same credential, and I would not need to have seperate per process > authentications to get the extra credential data for things like > SMB client FSs, etc.). The changed behaviour means I can't easily > have that in the future. It makes session management a pain in > the neck, and just that much harder to implement. Actually, assuming none of your processes are setuid, they will all point to the same credential. In fork() we simply bump the refcount on the ucred, we don't actually duplicate it into another ucred. > I think that for the NFS case, the best thing to do would be to > create a persistant "root" credential, and pass that, instead. So long as this doesn't give out extra privilege. > Doing anything else is likely to break somewhere, even if FreeBSD > never implements client cacheing (NFSv3 permits it over the lifetime > of a lease; NFSv4 practically demands it to get the best performance). I fail to see why using the actual credential from the requesting process instead of blindly granting root privileges will break client caching. If anything, I'm inclined to view it the other way around, but that's just me. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message