On Mon, Jul 10, 2006 at 03:45:49PM -0700, Jason Thorpe wrote:

> void
> lwp_cache_creds(proc_t p, lwp_t l)
> {
> 	ocreds = NULL;
> 	mutex_lock(&p->p_cred_mutex);
> 	if (l->l_cred != p->p_cred) {

On the platforms I'm aware of we should be able to do the test before the
lock, because only the current thread can modify l->l_cred and the read of
p->p_cred is atomic.

> >But doing the above has an impact on changing credentials. We will  
> >return
> >success on changing credentials before we've realy finished the  
> >change.
> >Yes, we've put things in place so the NEXT system call will use the  
> >new
> >creds, we are still using the old ones. If the unchanged LWP stays  
> >in the
> >kernel "for a while", then we have a measure of shadiness.
> 
> Assuming that an LWP entered the kernel with rights to perform an  
> action, it stands to reason that it should be allowed to complete  
> that action.

I haven't been able to think of a definite situation where we want to update
credentials in flight. This is a one good reason for review though! In such
cases, the code can always call lwp_cache_creds() or whatever as necessary.

Where we are considering processes as an object, such as for signalling, we
would still need to consider p->p_cred which would require locking, but this
case is a lot rarer.
 
> >How do other OSs handle this? Do they care?
> 
> I haven't looked into how the "change creds of the proc while threads  
> are blocked in the kernel" aspect, but I know that Mac OS X 10.4 has  
> per-thread credentials.  The AFP server uses this to ensure that  
> requests are processed as the user logged into the session.

Both FreeBSD and Solaris do delayed update of credentials in a similar way
to the one that I propose.

As an aside, I read somewhere that AIX also has true per-thread credentials.

Andrew