mwm@eris.BERKELEY.EDU (Mike (No one lives forever.) Meyer) (03/18/87)
In article <15136@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes: >How it works: > When you log in, your effective group ID is set to the number > in the group field of your "/etc/passwd" entry. Your group > set is initialized from { group ID in "/etc/passwd" } (union) > <set of groups in "/etc/group" that you belong to> (although Not quite, Guy. I think it's just confusing terminolgy, though. Your effective group id is set from the group field in /etc/passwd. Your group set is the set of groups your in /etc/group, EXCEPT for the group that is your group id. The operation is set difference, not union. In addition, if you use the setregid system call to set your real group id to a group that's in your group set, it will be taken from your group set. A second setregid back to the original group id will not put things back, so that the group will have vanished from your group set. The semantics of the gid/group set aren't very clean. If you're going to be writing code that dynamically deals with either one, be carefull, or you'll surprise yourself. Finally, notice that Guy's limit of 16 users is 4.3BSD. It was 8 in 4.2. <mike -- But I'll survive, no you won't catch me, Mike Meyer I'll resist the urge that is tempting me, ucbvax!mwm I'll avert my eyes, keep you off my knee, mwm@berkeley.edu But it feels so good when you talk to me. mwm@ucbjade.BITNET
aglew%mycroft@gswd-vms.arpa (Andy Glew) (03/19/87)
...> Groups in 4BSD
In a previous post someone said <<4.2 BSD's group system makes
System V style chown'ing by non-root unnecessary - newgrp isn't
necessary in BSD>>. To which I made the rather cryptic comment
<<Only 16 groups. Newgrp isn't necessary. Really?>>
I apologize for being cryptic. What I meant to say was that BSD does
have the equivalent of newgrp - it's just not accessible to the user.
As is obviously necessary when you could possibly be a member of an
>NGROUPS groups. So I reject "newgrp isn't necessary". Newgrp isn't
AS necessary, but it's still occasionally necessary.
16 is too small a number. There should be a way to dynamically add groups
to your group set, with some sort of replacement algorithm. I don't
accept "static during your terminal session"; effectively, it's globally
static, unless you allow people to do their own editing of /etc/groups,
if only to reorder the list of groups and determine which subset of
the greater than 16 groups they belong to are installed as their groupset.
Of course, there is a way - setgroups(2), with setgid(2) for the first
function, changing the default gid for file creation. Unfortunately,
setgroups is a super-user call.
So there is a need for newgrp - although it's provided as a system call,
not a "standard" command. This breaks the rule "anything you can do in C
should have a command level interface".
Obviously, the command level interface for setgroups would be a setuid
program that checked whether the groups that the user is requesting
be added (set) into his active groupset are permitted to him.
Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew
1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms.arpa