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

[Harti Brandt]

On Fri, 18 Nov 2005, Bruce Evans wrote:

BE>On Thu, 17 Nov 2005, Robert Watson wrote:
BE>
BE>> On Thu, 17 Nov 2005, Hartmut Brandt wrote:
BE>> 
BE>> > harti       2005-11-17 12:19:19 UTC
BE>> > 
BE>> >  FreeBSD src repository
BE>> > 
BE>> >  Modified files:
BE>> >    usr.sbin/rpc.lockd   kern.c
BE>> >  Log:
BE>> >  When a user is in more than 16 groups the call to authunix_create() will
BE>> >  result in abort() beeing called. This is because there is a limit of
BE>
BE>Is this for a remote user?  {NGROUPS_MAX} is 16, so a local user cannot be
BE>in more than 16 groups, and there are local bugs involving the egid hack
BE>which break other things for users in even 16 groups, so more than 14 or
BE>15 groups should not be used.

I have to integrate a number of FreeBSD and Linux machines into an active 
directory environment. This has a couple of thousands of users and around 
2500 groups. It extensively uses groups to control access to files on the 
file servers, so, for example, my account ends up in beeing in 36 groups 
(at the moment). I have bumped NGROUPS_MAX to 64 and most things work.

BE>
BE>The egid hack is "#define cr_gid cr_groups[0]".  This requires putting
BE>the egid in groups lists as the first entry.  IIRC, it is optional in
BE>POSIX for the egid to be in groups lists, and the implementation is
BE>broken since it doesn't remove all duplicate entries.  So instead of 16
BE>_supplemental_ groups (extra groups other than the egid), FreeBSD has
BE>only 14 or 15 supplemental groups depending on whether the optional
BE>egid is included once or twice in groups list.  I think 1 duplicate
BE>gets removed somewhere, so 15 groups work in practice, but reducing
BE>{NGROUPS_MAX} to 15 still wouldn't be POSIX conformant since the 16th
BE>groups is visible in some cases.
BE>
BE>> >  the number of groups in the RPC which is 16. When the actual number of
BE>> >  groups is too large it results in xdr_array() returning an error which,
BE>> >  in turn, authunix_create() handles by just calling abort().
BE>> > 
BE>> >  Fix this by passing only the first 16 groups to authunix_create().
BE>
BE>If it is an RPC limit, then shouldn't the protocol require senders to
BE>not send more and say what to do if they do?

It is a limit in the RPC. See <rpc/auth_unix.h>. The patch limits the 
FreeBSD side of rpc.lockd to send not more than 16 groups (these are 
groups 1-16 of the group array). If it receives more than 16 it will 
probably drop the request (I've not tried it). It just 'should not 
happen'.

BE>
BE>> It might be nice to add a comment to params.h by the definition of
BE>> MAXGROUPS pointing at this and any other known gotchas.  We've had a number
BE>> of requests
BE>
BE>MAXGROUPS doesn't exist.  Do you mean NGROUPS_MAX or the compatibility
BE>cruft NGROUPS?  I think increasing NGROUPS_MAX would increase compatibility
BE>for servers and reduce it for clients.

Works fine for me (on the client side). Before increasing it, I could not 
even login, because setgroups() failed in login(1).

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

Making it just larger but keep it static would help a lot. 16 groups just 
isn't enough for larger environments (another unix-like os uses 63 or 64).

harti