On Jul 10, 2006, at 3:30 PM, Bill Studenmund wrote:

> I'm not sure about the cause&effect here. :-) I DO agree that we don't
> want an lwp to change credentials in the middle of a systemcall.  
> However a
> shared lock with upgrade to exclusive will also do that. :-)

1- Shared -> Exclusive "upgrades" are an icky concept that we happen  
to have in lockmgr(), but I would prefer we NOT proliferate.

2- The key to scalability is to AVOID locking where you can.  Why  
block another thread that wants to change the process's credentials  
just because another thread in the same process is waiting for disk I/ 
O?  You avoid contention for the lock when you have a nice short code  
path like this:

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) {
		ocreds = l->l_cred;
		l->l_cred = p->p_cred;
		kauth_cred_retain(l->l_cred);
	}
	mutex_unlock(&p->p_cred_mutex);
	if (ocreds != NULL)
		kauth_cred_release(ocreds);
}

...and you don't have to take the lock again.

Let's try and design for scalability NOW rather than have to retrofit  
it in later.


> 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.

> 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.

-- thorpej