setgroups problems on FreeBSD - proposed fix

[James Peach]

On May 23, 2007, at 9:21 AM, Bjoern Jacke wrote:

> Hi James,
>
> On Wed, May 23, 2007 at 08:35:46AM -0700, James Peach wrote:
>> FWIW, Darwin does the same as FreeBSD ...
>
> maybe you can bring some light into the dark here: I did some tests  
> with
> Darwin (OS X with most recent patches) to see how it behaves with the
> maximum number of supplementary groups. sysctl says ngroups max is 16
> like on all *BSD systems.
>
> I saw that it is quite difficult to actually add any new groups on an
> OS X client machine. I found that it is possible to add groups if you
> download 50MB ServerAdminTools from Apple and connect to the  
> "localhost"
> server with the workgroup manager tool. This was the only way I found
> out on OS X to add new groups, is there an easier way to create/manage
> groups?

I use dscl and dseditgroup, but the ServerAdmin tools are what you are  
supposed to use. I think that most users of desktop system don't have  
much need to be adding groups :)

http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/dscl.1.html
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man8/dseditgroup.8.html

> Then I put myself into 17 newly created groups but "id" was saying  
> that
> I would only be in 15 groups (including the group which is reported
> to be my primary group - but I don't know if OS X is actually making a
> difference between primary and supplementary groups internally, does  
> it?).

The kernel cred has an array of 16 groups and the first element is  
your primary gid. I don't know whether the kernel treats these any  
differently when making authorisation decisions.

> So on OS X it only seems to be possible to have 14 supplementary  
> groups
> at all. Is this by design?

The answer is both yes and no :)

Darwin has true nested groups and users can be in an unlimited number  
of groups. Unfortunately calling setgroups(2) disables this behaviour  
and gives you 1 primary + 15 supplementary. This is for standards  
conformance reasons.

Now normally what happens is that the Directory Services guarantees to  
answer the question "is user X a member of group Y". It does not  
provide a method to enumerate all the groups a user is a member of,  
and I don't know a way to do that. In this case, the supplementary  
groups list is best thought of as a group membership cache (though  
there are also other levels of caching involved). When the kernel  
needs to make an authorisation decision that might depend on the user  
being a member of a specific group, it calls out to Directory Services  
to check the user's group membership.

http://developer.apple.com/documentation/Darwin/Reference/ManPages/man8/memberd.8.html

So every process gets on the memberd path by default. If you call  
setgroups or otherwise mess with your credential, you get kicked off  
the memberd path. getgroups(2) will simply not return your full group  
list if you have more than 16.

If you did through the Darwin mailing lists, there is probably a post  
from Terry Lambert explaining this better than I can.

--
James Peach | jpeach at samba.org