setgroups problems on FreeBSD - proposed fix
jpeach at samba.org
Wed May 23 17:24:03 GMT 2007
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
> 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
> 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
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 :)
> Then I put myself into 17 newly created groups but "id" was saying
> 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
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
> 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
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.
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
More information about the samba-technical