Xref: utzoo comp.unix.questions:4825 comp.unix.wizards:5793
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!ames!amdahl!cerebus!wjvax!brett
From: brett@wjvax.UUCP (Brett Galloway)
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: Re: Setting up groups
Message-ID: <1167@wjvax.UUCP>
Date: 16 Dec 87 21:02:00 GMT
References: <4718@well.UUCP> <578@aoa.UUCP>
Reply-To: brett@wjvax.UUCP (Brett Galloway)
Organization: Watkins-Johnson Co., San Jose, Calif.
Lines: 54

In article <578@aoa.UUCP> mbr@aoa.UUCP (Mark Rosenthal) writes:
>In article <4718@well.UUCP> samlb@well.UUCP (Samuel B. Bassett) writes:
>>	How do you assign a user to more than one group?
>Berkeley had a better idea.  They modified the kernel to keep a list
>of groups rather than a single group.  Thus, when you log in they build
>a list consisting of the GID found in the /etc/passwd file and all the
>groups you belong to specified in the /etc/group file.  If you don't own a
>file, but the GID of the file appears in your group list, your access is
>controlled by the group permissions on the file.  You will see this scheme
>in the 4.?bsd versions of Unix.  With this arrangement, there is no longer
>any need for a 'newgrp' command, so it was removed.  Also, note that the
>group in /etc/passwd is not any more special than any of the groups you belong
>to by virtue of being mentioned in /etc/group.  In 4.?bsd, there is really no
>longer any reason to have any group information in /etc/passwd.  I assume they
>kept the field because it would have broken too many programs and shell scripts
>if they changed the format of /etc/passwd.  And as long as you've got the field
>there, you might as well make it part of the group list along with the info
>in /etc/group.

I agree that it is kind of stupid to have group assignments in two different
files.  However, I always thought it would be more useful to specify the
group list in /etc/passwd (so all the user-dependent stuff is in one
place), and then permit some other use for the information in /etc/group.
One candidate would be group expansions, i.e.

	/etc/passwd:
		brett::765:0,81:Brett Galloway:/u1/brett:/bin/csh

	/etc/group:
		wheel:*:0:staff
		staff:*:10
		user:*:80
		aduser:*:81:user
		synuser:*:82

In this example, I would be in groups 0 (wheel) and 81 (aduser), but group 0
would also provide access to group 10, and group 81 would provide access to
group 80, so I would be in four groups total (0,10,80,81).

The processing of /etc/group would be straight-forward enough (just change
initgroups(3X) appropriately).

This would centralize all of the user-dependent stuff in /etc/passwd.  Allowing
group expansion in /etc/group would also simplify the handling of multiple
groups; often, one has a hierarchy of groups which could be expressed
statically in the /etc/group file.  In these cases, multiple groups could be
assigned easily without embedding any of that knowledge in the /etc/passwd
file.  The above example says in the /etc/passwd file that I am a wheel user
and I am in user group 'aduser`.  The /etc/group file then says that wheel
users are also in group staff and aduser users are also in group user.
-- 
-------------
Brett D. Galloway
{ac6,calma,cerebus,isi,isieng,pyramid,tymix}!wjvax!brett