Date: Fri, 29 May 2009 15:54:33 -0700 From: Zachary Loafman <zml@FreeBSD.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: steven.danneman@isilon.com, freebsd-arch@freebsd.org Subject: Re: pthread_setugid_np Message-ID: <20090529225432.GC27779@isilon.com> In-Reply-To: <alpine.BSF.2.00.0905290937430.86277@fledge.watson.org> References: <20090528000147.GB3704@isilon.com> <alpine.BSF.2.00.0905290937430.86277@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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); void pthread_clearcred_np(); .. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090529225432.GC27779>