Re: [cobalt-users] 32 Group Limitation

[Duncan Laurie <duncan@xxxxxxxxxxxxxxxxxx>]

unfortunately the 32 group problem goes a bit deeper...

the limit stems from a Sun NFS2 limitation (32 is actually up from NFS'
original limitation of 16 groups).. It is defined in linux kernel (both
2.0.* and 2.2.*) to be 32.  luckily NGROUPS is not a bit-field (that would
instantly break almost anything compiled against it) but a number of
statically allocated arrays in the kernel that is used to hold a users
egids.

so our first reaction when we discovered this during raq2 testing (it
actually became a real issue for the NASRaQ and its ability to sync with
NT domain masters) was to up this limit, recompile the kernel and move on.

while it is possible that *certain* things would work if the limit was
upped and the kernel was recompiled, this would cause unknown havoc
and certainly would break some NFS compatibility (especially with Sun
servers).. 

it doesn't appear to directly and obviously break anything, but it also
doesn't work.  stat(2) calls (used to retrieve inodes) fail with an
EACCESS error in the kernel, and id(1) on the user side will most likely
break somewhere down the line...

at a minimum you would need to recompile the kernel, then glibc, and then
linux-PAM, and possibly any other static (and maybe dynamic) linked
programs that have anything to do with groups (i.e. calls getgrpid,
getgroups, setgroups, initgroups, in_group_p, in_egroup_p, etc...).  even
though PAM exists to simplify much of the authentication process, many
programs still directly call getgroups(2) with 32 as the first parameter
(which will return only the first 32 groups), or setgroups(2) and fails to
properly check for an EINVAL error.

other possible solutions are separation of our "universal" admin account
from every virtual site group, or using an external database for
authentication, or ... the list could go on.  the easiest solution is to
use root instead of admin for necessary administration; but of course you
don't want to use that with things like FTP or direct telnet, but it IS
the easiest answer. . other ideas are for kernel 2.4 (and ext3 and glibc2
and linux-PAM) to break the system and up the NGROUPS limit in the
distributed sources, but i wouldn't count on that happening anytime soon.

in any case, we are *painfully* aware of the limitation, and are looking
for solutions..

later,
-duncan


On Tue, 21 Dec 1999, Robert G. Fisher wrote:

> On Tue, Dec 21, 1999 at 02:48:58PM -0800, Lyle Scheer wrote:
> > You are correct.  It stems from a Linux limitation that a user on a Linux
> > machine can be in no more than 32 groups.... you can put them in more than
> > 32 groups in the /etc/groups file, but they will only show up in the first
> > 32.  We were not aware of this when we designed our interface to handle
> > virtual sites, and it came up in our SQA testing, but unless we totally
> > rework the way we handle groups and virtual site, or patch Linux itself, we
> > cannot get around this.
> 
> Has there been any testing on a cobalt of a 'patched' kernel -- after
> all,  it is only one line in limits.h that we're talking about here
> where it reads:
> 
> #define NGROUPS_MAX	32	/* supplimental group IDs are available */
> 
> -- 
> Robert G. Fisher		     NEOCOM Microspecialists Inc. 
> System Administrator/Programmer      (540) 666-9533 x 116
> 
> _______________________________________________
> cobalt-users mailing list
> cobalt-users@xxxxxxxxxxxxxxx
> http://list.cobalt.com/mailman/listinfo/cobalt-users
>