mwm@ucbopal.BERKELEY.EDU (Mike (I'll be mellow when I'm dead) Meyer) (02/10/86)
In article <235@hadron.UUCP> jsdy@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