Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!jade!ucbcad!ames!hao!noao!arizona!whm
From: whm@arizona.edu (Bill Mitchell)
Newsgroups: comp.unix.wizards
Subject: Re: NGROUP limit set at 8
Message-ID: <2617@megaron.arizona.edu>
Date: Thu, 29-Oct-87 22:41:33 EST
Article-I.D.: megaron.2617
Posted: Thu Oct 29 22:41:33 1987
Date-Received: Wed, 4-Nov-87 04:24:42 EST
References: <9096@mimsy.UUCP>
Organization: U of Arizona CS Dept, Tucson
Lines: 23

We too find the eight-group limit a little tight, but it doesn't look like
there's much hope of getting it raised any time soon.  Something we've been
considering is making a distinction between groups that are used for file
access and groups that are used for things like printcap's "rg" (restricted
group).  The idea is pretty simple: Have the groups that are used for file
access be numbered less than N (say, 500) and then have initgroups(3) add
only those groups to a process's group vector (via setgroups(2)).

So, if you've got a couple of groups for printer access, a group or two used
by a certain program to allow or disallow something, etc., you don't need
to sacrifice any of the eight precious slots in the group vector.

Of course, this depends on the fact that most programs that use the /etc/group
information to determine membership of some sort use the getgrnam(3) call
and not getgroups(2) (which would also be the long way around).

We haven't done it, but the changes are pretty simple, I think: add a line or
two of code to initgroups() and then recompile programs that use it.  Two that
come to mind immediately are login and su, and there are probably a few others.

					Bill Mitchell
					whm@arizona.edu
					{allegra,cmcl2,ihnp4,noao}!arizona!whm