Gid's in 4.2

[Mike I'll be mellow when I'm dead Meyer]

In article <235 at hadron.UUCP> jsdy at hadron.UUCP (Joseph S. D. Yao) writes:
>Under 4.2 BSD, processes still have group-id's, the way humans still
>have appendices.  They aren't used for anything I can see.

Try looking in /usr/adm/acct. You'll find that the group id is dumped there,
*not* the group vector. You can use the group id to slice billing out at a
higher level than the user.

Having had to do this, *plus* re-implement newgroup to allow people to
change billing groups (we did consulting; user id's corresponded to users,
group id's < 100 were used for file protection, and group id's > 100
corresponded to customer accounts), I'd like to warn people about a quirk in
the semantics of the setgid system call (similar comments apply to the
setregid system call).

When you do a setgid(gid), the kernel makes sure that the process is in gid
only *once*. It sets the process group id to gid, then deletes gid from the
group vector if gid is in it. Notice that nothing got done with the old
group id. It's gone. So, a sequence like such could occur:

		Group ID		Group Vector
start
		510			1, 3, 5, 7, 9, 619
do setgid(619)
		619			1, 3, 5, 7, 9
do setgid(510)
		510			1, 3, 5, 7, 9

Note that 619 has dissappeared. This is why the protection and accounting
groups have to be disjoint: you want to make *sure* that nobody does a
newgrp to a group that is in their group vector, or it will dissappear.

	<mike