On 23rd January, I asked some questions about UNIX groups.
This is a very much delayed (apologies) summary of the replies.
Information was provided by:
Ric Anderson <firstname.lastname@example.org>
"Anthony A. Datri" <email@example.com>
John Hasley <firstname.lastname@example.org>
stpeters @ com.ge.crd.dawn
dupuy @ edu.columbia.cs.hudson
Robert L Krawitz <email@example.com>
James Davenport <firstname.lastname@example.org>
drl @ edu.vanderbilt.vuse
mark @ com.deltam
David LeVine <email@example.com>
leo @ edu.mit.ai
del @ com.harris.semi.mlb
blanchar @ edu.unc.med
beig @ earn.frulm63
rick @ uk.ac.man.mb.wiau
to whom much thanks.
There were several "tell me too" requests.
The questions follow, interspersed with my summary of the replies;
I hope I have understood correctly! I have not actually pushed
at these limits yet, so cannot confirm/deny them.
> Good progress is being made with rationalising the uid/gid space
> and departments are willing and keen to conform to this.
Incidentally, several people enquired about this.
Primarily, we attempt to maintain good will with other departments,
pointing out benefits such as the automounter, if we adopt common
conventions (uid/gid, home directory structure ...).
Secondarily, but practically, we hold uid/gid information on all staff
and students in an INGRES database. We plan to allow all system
administrators to see enough of it to allow them to join users to
their own machines. The information we hold is itself gleaned from
files sent to us by the University Administration department.
> We have two (probably more!) unresolved questions about groups:
> 1. Group membership:
> a. Is there a maximum number of members to a group?
> (Counting through the "passwd" file.)
No known limit.
> b. Is there a maximum number of additional members a group may
> have? (Last field of an entry in the "group" file.)
For non-NIS, most respondents thought there was no limit, although one
thought that BUFSIZ (I assume "/usr/include/stdio.h") might be a limit.
For NIS, the "dbm(3x)" routines limit a single group entry to
just under 1024 bytes. Apparently it is possible to work around this
by creating several groups with the same GID.
> c. Do "a" and "b" interact?
No known interactions.
> d. Is there a maximum number of groups to which a user may belong?
> (SunOS pre-4.0 has a limit of 8 according to "group(5)";
> however, we are strongly encouraging our departments towards
> at least 4.0.3, preferably 4.1 or 4.1.1 .)
"/usr/include/sys/param.h" defines NGROUPS. From 4.0, this value is 16.
Some manufacturers go lower, some go higher.
BUT ... in a mixed environment using NFS, it is very unwise to exceed 8.
> 2. We follow SUN's defined groups:
> a. "staff" (group 10) is useful for installing applications
> because of directory ownership within SunOS;
> b. "operator" (group 5) is useful for disk backup (disk device
> ownership and permission) and shutdown procedures.
> But is all this SUN-specific? Do heterogeneous sites have
> other approaches and/or solutions?
Every vendor is different, so it seems, in defining their groups.
Generally, the solution adopted is either to live with it,
or to attempt to select the most popular machine as a local "standard"
and to (attempt to) coerce the others to fall in line.
More generally, there was a message on sun-managers on 6 Dec 1990
from "firstname.lastname@example.org" outlining approaches to handling
large user populations.
Other sources have hinted that it may be wise to keep ordinary user
uids and gids away from the 0-1000 range. The firmness of this advice
is inversely proportional to the u/gid, so that this advice may be
meaningless in 100-999, should be noted in 50-99, and obeyed below 50.
(Having said that, we have just this week received UNIRAS 6.2a which
says it requires to use both uid and gid 21149!).
: David Lee Computer Centre :
: University of Durham :
: Phone: +44 91 374 2882 (ddi) South Road :
: Fax: +44 91 374 3741 Durham :
: ARPA: T.D.Lee@durham.ac.uk U.K. :
: JANET: T.D.Lee@uk.ac.durham :
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:12 CDT