First off, let me just say that I really appreciate such a thorough
response. It was a pleasure to read. :)
On Fri, May 29, 2009 at 09:48:33AM +0100, Robert Watson wrote:
> Having spent some time investigating and using the APIs on Mac OS X in
> the last year, I can report that their usage is at times inconsistent.
This is one of the things I don't really like about the standard APIs,
either. If I were to deviate from the Mac OS X API, I would propose
something more along the lines of two calls:
int pthread_setcred_np(uid_t uid, int ngroups, const git_t *gidset);
.. where clearcred is used to change the thread back to per-process
credentials. I don't really like using an artifical ID for clearing it.
Setting the uid and groups in the same call would provide a clue to the
application writer that the supplemental group list should be considered
as well. Combining the setuid and setgroups into one call also has
internal advantages in that no intermediate cred is ever created.
As it is, the OS X APIs are a little kludgy around setgroups. Unless I'm
misunderstanding something, you can't really tell if setgroups() is
modifying the per-process or per-thread credentials unless you also know
whether the thread is running with per-thread credentials.
> Per-thread credentials also require semantics that effectively preclude
> M:N threading with usersapce context switching being used in the future
I hadn't really thought much about that, because I thought M:N was
effectively dead. :)
> There are also potential concerns about other credential elements, such
> as MAC labels provided by policies that assume timely update of the label
I'm going to have to research this point a little more thoroughly, I
haven't looked at the MAC interaction here.
> but it's worth watching out for this. Apple addressed the problem by
> doing a coalesce stage after creating and initializing a new credential,
> in which potential existing credentials with identical contents are
> searched for and then used instead, discarding the new one, which comes
> with some overhead.
This is somewhat of a concern for us, yes. In theory, the number of
unique creds for us is roughly bounded by the number of active
connections. However, in a multithreaded server that swaps to per-thread
credentials to do Real Work, the number of creds in a naive system would
end up more on the order of the number of open files. I'm not sure
that's a huge concern for us, though.
In theory, we might also be able to de-dupe in the background.
Serialization is a concern, but it seems doable. That wouldn't incur the
active overhead of keeping a cred cache.
Longer term, we may be interested in working on a cred cache, too. We
have other motives behind this, though: we're looking at storing
alternate identities in the cred, and given the expensiveness of mapping
in certain circumstances it makes a lot more sense to just hunt for an
existing cred that matches.
Zach Loafman | Staff Engineer | Isilon Systems