From owner-freebsd-arch@FreeBSD.ORG Fri May 29 22:54:47 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5D40106564A for ; Fri, 29 May 2009 22:54:47 +0000 (UTC) (envelope-from zml@FreeBSD.org) Received: from seaxch10.isilon.com (seaxch10.isilon.com [74.85.160.26]) by mx1.freebsd.org (Postfix) with ESMTP id B61EF8FC17 for ; Fri, 29 May 2009 22:54:47 +0000 (UTC) (envelope-from zml@FreeBSD.org) Received: from famine.isilon.com ([10.54.190.95]) by seaxch10.isilon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 May 2009 15:54:35 -0700 Received: from zloafman by famine.isilon.com with local (Exim 4.69) (envelope-from ) id 1MAAy9-0001tt-UU; Fri, 29 May 2009 15:54:33 -0700 Date: Fri, 29 May 2009 15:54:33 -0700 From: Zachary Loafman To: Robert Watson Message-ID: <20090529225432.GC27779@isilon.com> References: <20090528000147.GB3704@isilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 29 May 2009 22:54:35.0495 (UTC) FILETIME=[70040F70:01C9E0B0] Cc: steven.danneman@isilon.com, freebsd-arch@freebsd.org Subject: Re: pthread_setugid_np X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 22:54:48 -0000 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