Date: Tue, 9 Oct 2001 17:14:44 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: John Baldwin <jhb@FreeBSD.org>, arch@FreeBSD.org Subject: Re: ucred API Message-ID: <Pine.NEB.3.96L.1011009170942.42878A-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.21.0110091301321.27416-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 9 Oct 2001, Julian Elischer wrote: > On Tue, 9 Oct 2001, John Baldwin wrote: > > > newcred = crget(); > > PROC_LOCK(p); > > oldcred = p->p_ucred; > > error = suser(oldcred); > > is suser being changed to take a cred? I currently plan to make this change unless there is any substantial objection. I, like John, have reams of outstanding patches relating to this code. :-) There used to be two reasons for suser to accept a proc pointer: (1) ASU flag set on process that checks for suser (bogus) (2) prison pointer in process (now in ucred) Since both of these have gone away, it would substantially simplify things to simply always select the credential before entering suser(), and leave it as: int suser(struct ucred *cred, int flags); I also have a switch from ucred -> cred in a local tree, as well as a complete capabilities implementation, and a fairly functional MAC implementation, plus gobs of other garbage that I'll probably trickle into the tree over the next few months. > I assume that you say "It won't change" because if the process's cred is > changed, it gets a new one and the thread's pointer still points to the > old one? (ref counted) After some thinking and talking with other UNIX vendors, it does seem to me that the most 'consistent' behavior can be accomplished by locking in the credential at the start of a system call, and maintaining it until the call completes. This is especially true for VFS calls. John's thread-based solution seems to encapsulate the associated concerns extremely well, and addresses my concerns about a variety of nasty races and non-determinism that might otherwise exist. Obviously, this is something that people should think through fairly hard, but I'm very happy with the solution (and if John drank beer, I'd buy him several -- this means I should buy him Soda at BSDCon, probably). 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.1011009170942.42878A-100000>