Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 09 Oct 2001 12:25:22 -0700 (PDT)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Julian Elischer <julian@elischer.org>
Cc:        arch@FreeBSD.org
Subject:   Re: ucred API
Message-ID:  <XFMail.011009122522.jhb@FreeBSD.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 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 <jhb@FreeBSD.org> -- 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.011009122522.jhb>