RFT: Allow large values of NGROUPS_MAX

From: Brooks Davis <brooks_at_freebsd.org>
Date: Fri, 5 Jun 2009 17:36:36 -0500
I've been working on fixing the limit of 15 groups per user.  This has
primarily consisted of merging a patch from Isilon Systems which breaks
the group array out of struct ucred and stores in in malloc'd storage.

I've attached a patch which includes that change and increases the value
of NGROUPS_MAX to 32767.  It also changes references to cr_groups[0] to
use the cr_gid macro and introduces a new crsetgroups() function for use
by random bits of code that fill in credentials (usually partial ones)
Additionally, a number of arrays that used to be of length NGROUPS have
been changed to use XU_NGROUPS (from xucred) or their own definition
which is 16 to avoid excessive bloat.  Most of these should probably be
change to use dynamic allocation.

In general, when something could not take more groups, I have chosen to
truncate the list rather than fail.  This may raise issues with negative
permissions, but complete failure is likely to cause problems for more
people.  If it's a major issue this can be made tunable.  As I mentioned
above, many thing should be redone to support dynamic allocation, but
all the RPC related things can not.

I'd like people to test and review this patch with the aim of getting it
and some of the other work I've been doing in subversion in to 8.0.  You
can find all of it at http://svn.freebsd.org/base/projects/ngroups.

Before any merge a couple decisions need to be made:

 - How large should NGROUPS_MAX be?  Linux uses 65536 and we could
   extend things to support that, but it's probably unnecessary.  

 - Should we make any attempt to support old binaries when there
   are more than 16 groups?  The POSIX getgroups/setgroups APIs did not
   anticipate this change and thus either will fail outright.  We can't
   fix setgroups, but we might want to make an optional accommodation for
   getgroups to allow for truncated returns to old code.

-- Brooks

Received on Fri Jun 05 2009 - 20:36:26 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:49 UTC