On Jul 10, 2006, at 4:45 PM, Bill Studenmund wrote:

> I perhaps was sloppy with "upgrade." I specificaly meant a reader/ 
> writer
> lock going from reader to writer mode. The exact "upgrade" behavior of
> lockmgr isn't important to the issue.

Going from "shared" -> "exclusive" is in fact the whole problem.   
It's ugly no matter how you look at it :-)

> Agreed. Right now, I think the only question is what we are  
> promising and
> what standards require.

SUSv3 is silent on the issue, as far as I can tell.  SCO UnixWare 7  
says this:

<quote>
Considerations for threads programming

This ID number is an attribute of the containing process and is  
shared by sibling threads.

</quote>

...which says nothing about the synchronization.

Linux pre-NPTL had the property that setuid only affected the calling  
thread, and Andrew's suggestion does not have that problem.

> Oh, that'd be "interesting" if we don't just stay in the kernel  
> since a
> given userland thread can hop around LWPs. :-)

Well, on OS X, threads don't hop around LWPs, so it's not really an  
issue (there is a 1-1 mapping between a pthread and a kernel thread  
in Mach threads).

Even with the hopping property, I don't think it would be that  
difficult to implement similar per-thread credentials -- it just  
becomes part of the thread context that is saved/restored.  I mean,  
the process already had the privileges to set the thread's  
credentials in the first place, so there is no danger in restoring it  
when the thread runs again.

-- thorpej