sjr@mimsy.UUCP (Stephen J. Roznowski) (10/26/87)
I've run across a problem with trying to be in more than 8 groups at once. The problem is that it seems that I need to rebuild the whole system to enlarge NGROUP (located in /usr/include/sys/param.h), because the C library uses param.h. Is there an easier solution? (Other than rebuilding the system) Is there a reason why the number of groups is limited to 8? (other that the fact that most people are in less that 8 groups...) A related question, how would you make this change on a binary only distribution? [If it matters, I'm using 4.[23]BSD and SunOS3.4] Thanks, Stephen Roznowski (sjr@mimsy.umd.edu) -- Stephen J. Roznowski sjr@mimsy.umd.edu
romain@pyrnj.uucp (Romain Kang) (10/27/87)
In article <9096@mimsy.UUCP> sjr@mimsy.UUCP (Stephen J. Roznowski) writes: | it seems that I need to rebuild the | whole system to enlarge NGROUP (located in /usr/include/sys/param.h), | because the C library uses param.h. | | Is there an easier solution? Under vanllia 4.2 BSD, I got a workable system by recompiling /usr/src/lib/libc/gen/initgroups.c replace initgroups.o in /lib/libc.a, /usr/lib/libc_p.a initgroup dependents: /usr/src/bin/{login.c,su.c} /usr/src/ucb/groups.c /usr/src/bin/{ps.c,adb/} /usr/src/ucb/{{w,gcore}.c,dbx/} /usr/src/etc/{pstat,analyze}.c (as well as the kernel, of course.) Under some NFS'd kernels, you might not need to recompile all of these, since the group array was moved out of the user structure. If you don't really need to be in all those groups simultaneously, you could simply re-implement the "newgrp" command using setgid() calls. | Is there a reason why the number of groups is limited to 8? (other | that the fact that most people are in less that 8 groups...) Last I looked, group permission validation was done by a linear scan of the group array. This occurs every time someone needs to open a file, etc. One could take a performance hit by raising NGROUPS willy-nilly. | A related question, how would you make this change on a binary only | distribution? I wouldn't try it. Youi'd probably have to hack binaries without symbol tables. Most people I know don't have that sort of time to kill.
stpeters@dawn.steinmetz (Dick St.Peters) (10/28/87)
In article <9096@mimsy.UUCP> sjr@mimsy.UUCP (Stephen J. Roznowski) writes: >I've run across a problem with trying to be in more than 8 groups >at once. The problem is that it seems that I need to rebuild the >whole system to enlarge NGROUP (located in /usr/include/sys/param.h), > >Is there an easier solution? (Other than rebuilding the system) No. NGROUP is used to size an array in the kernel ucred (user's credentials) structure when building a kernel. >A related question, how would you make this change on a binary only >distribution? Even binary distributions come with a configuration source file /usr/sys/conf/param.c, compiled when you build a kernel. This #include's "../h/param.h", which defines the NGROUP value for the kernel. If you change NGROUP there, you probably ought to change it in in /usr/include/sys/param.h also. -- Dick St.Peters GE Corporate R&D, Schenectady, NY stpeters@ge-crd.arpa uunet!steinmetz!stpeters
guy%gorodish@Sun.COM (Guy Harris) (10/28/87)
> No. NGROUP is used to size an array in the kernel ucred (user's > credentials) structure when building a kernel. Unfortunately, these credentials are used when the kernel makes an RPC call (e.g., for an NFS operation), and are also used indirectly when user-mode code makes RPC calls (the RPC code does a "getgroups" system call). The number of groups in UNIX-authentication credentials for Sun RPC is 8 (not 10, the RPC Protocol Specification lies), so it can't handle more than 8 groups. This means that RPC calls using UNIX authentication (such as NFS calls) won't work if you crank the number of groups above 8. The authentication scheme described in a paper by Brad Taylor and Dave Goldberg at the 1986 summer USENIX conference ("Secure Networking in the Sun Environment") would solve this problem, because you don't pass UNIX user and group IDs over the wire; you pass a name that gets translated to an appropriate set of credentials as understood by the local OS (which need not be UNIX). > Even binary distributions come with a configuration source file > /usr/sys/conf/param.c, compiled when you build a kernel. However, there are plenty of source files *not* supplied with a binary distribution that make use of NGROUPS, and "/usr/sys/conf/param.c" doesn't make use of it, so changing "NGROUPS" in "param.h" and rebuilding won't help. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
djl@mips.UUCP (Dan Levin) (10/29/87)
In article <32169@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: > > No. NGROUP is used to size an array in the kernel ucred (user's > > credentials) structure when building a kernel. > > Unfortunately, these credentials are used when the kernel makes an RPC call > (e.g., for an NFS operation), and are also used indirectly when user-mode code > makes RPC calls (the RPC code does a "getgroups" system call). The number of > groups in UNIX-authentication credentials for Sun RPC is 8 (not 10, the RPC > Protocol Specification lies), so it can't handle more than 8 groups. This > means that RPC calls using UNIX authentication (such as NFS calls) won't work > if you crank the number of groups above 8. Not only that, but the cred struct passed over the net for UNIX auth includes a size field for the group list (aup_len). It was clearly the original idea to allow variable size group lists, but the number 8 is hard coded into the SUN RPC implementation, even though the comment just above says 10 (as does the spec...). Interesting that the leading implementation of a supposedly public domain protocol doesn't follow the spec... NB: This is a pet peeve of mine, as the group length issue came up while doing NFS/RPC for UMIPS-BSD, a 4.3 based kernel. -- ***dan {decwrl,pyramid,ames}!mips!djl djl@mips.com (No, Really! Trust Me.)
whm@arizona.edu (Bill Mitchell) (10/30/87)
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!whmstpeters@dawn.steinmetz (Dick St.Peters) (11/01/87)
In article <850@winchester.UUCP> djl@mips.UUCP (Dan Levin) writes: >the number 8 >is hard coded into the SUN RPC implementation, even though the comment >just above says 10 (as does the spec...). Interesting that the leading >implementation of a supposedly public domain protocol doesn't follow >the spec... More likely it is the spec documentation that's wrong, since the limit of 8 seems to pervade BSD and derivatives. Of course, if you're my age and think in octal instead of hex ... -- Dick St.Peters GE Corporate R&D, Schenectady, NY stpeters@ge-crd.arpa uunet!steinmetz!stpeters