From owner-freebsd-arch Tue Oct 9 12:26: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with ESMTP id 23B5E37B407 for ; Tue, 9 Oct 2001 12:25:57 -0700 (PDT) Received: (qmail 34570 invoked from network); 9 Oct 2001 19:25:56 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 9 Oct 2001 19:25:56 -0000 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: Date: Tue, 09 Oct 2001 12:25:22 -0700 (PDT) From: John Baldwin To: Julian Elischer Subject: Re: ucred API Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 09-Oct-01 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? Not now, but I think that is on Robert's plans for the future. That should be suser(p) I suppose. suser() really has nothing to do with threads or processes but only ucred's anyways. >> if (error == 0) { >> crcopy(newcred, oldcred); >> >> Stage 2: >> - Add a per-thread reference to the ucred that is created on syscall >> entry and released on syscall exit. It is also created and released >> if needed on trap enter/exit. It is _not_ created for interrupts >> since >> interrupts should not care about the ucred of their borrowed context. >> The per-thread ucred reference will then point to a ucred that won't >> ever change (setuid, etc. update the per-process ucred) and thus won't >> need any locking. Almost all references to ucreds for suser(), VOP's >> etc. will use the thread reference. This will ensure that a thread's >> ucred will be the same for an entire syscall which will close many >> races involving multithreaded programs and ucreds. The only place >> where >> the per-process ucred will be used for access checks is places that >> modify the ucred as we want to ensure there is no race of one thread >> making a credential change it isn't qualified to make due to it >> performing >> its access checks on a stale ucred before updating the master ucred. > > 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) Right. -- 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