Subject: Re: Process credentials change
To: Bill Studenmund <email@example.com>
From: Jason Thorpe <firstname.lastname@example.org>
Date: 07/10/2006 21:02:00
On Jul 10, 2006, at 4:45 PM, Bill Studenmund wrote:
> I perhaps was sloppy with "upgrade." I specificaly meant a reader/
> 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
Considerations for threads programming
This ID number is an attribute of the containing process and is
shared by sibling threads.
...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.