cvs commit: src/usr.sbin/rpc.lockd kern.c

Bruce Evans bde at
Thu Nov 17 21:26:43 GMT 2005

On Thu, 17 Nov 2005, Robert Watson wrote:

> On Thu, 17 Nov 2005, Hartmut Brandt wrote:
>> harti       2005-11-17 12:19:19 UTC
>>  FreeBSD src repository
>>  Modified files:
>>    usr.sbin/rpc.lockd   kern.c
>>  Log:
>>  When a user is in more than 16 groups the call to authunix_create() will
>>  result in abort() beeing called. This is because there is a limit of

Is this for a remote user?  {NGROUPS_MAX} is 16, so a local user cannot be
in more than 16 groups, and there are local bugs involving the egid hack
which break other things for users in even 16 groups, so more than 14 or
15 groups should not be used.

The egid hack is "#define cr_gid cr_groups[0]".  This requires putting
the egid in groups lists as the first entry.  IIRC, it is optional in
POSIX for the egid to be in groups lists, and the implementation is
broken since it doesn't remove all duplicate entries.  So instead of 16
_supplemental_ groups (extra groups other than the egid), FreeBSD has
only 14 or 15 supplemental groups depending on whether the optional
egid is included once or twice in groups list.  I think 1 duplicate
gets removed somewhere, so 15 groups work in practice, but reducing
{NGROUPS_MAX} to 15 still wouldn't be POSIX conformant since the 16th
groups is visible in some cases.

>>  the number of groups in the RPC which is 16. When the actual number of
>>  groups is too large it results in xdr_array() returning an error which,
>>  in turn, authunix_create() handles by just calling abort().
>>  Fix this by passing only the first 16 groups to authunix_create().

If it is an RPC limit, then shouldn't the protocol require senders to
not send more and say what to do if they do?

> It might be nice to add a comment to params.h by the definition of MAXGROUPS 
> pointing at this and any other known gotchas.  We've had a number of requests

MAXGROUPS doesn't exist.  Do you mean NGROUPS_MAX or the compatibility
cruft NGROUPS?  I think increasing NGROUPS_MAX would increase compatibility
for servers and reduce it for clients.

> to support significantly extended groups in FreeBSD, and I did some initial 
> hacking on variable length group storage for credentials but didn't bring it 
> to completion.  If this is something you're interested in looking at though, 
> I'm happy to spread the pain :-).

The pain for making file descriptor starage variable has been spread across
about 20 years.


More information about the cvs-src mailing list