One thing that is missing in traditional Unix systems is the ability to let a non root user manage group membership. Unix was built around several simple concepts. One of those was: everything is a file. Using this principle, we can specify how group delegation would have worked.
One concept that has taken hold in the past decade is providing a complete directory for subsystem configuration. If we extend this to groups, delegation becomes easy.
Instead of group membership being an single file, we do one file per group:
/etc/groups.d
Management of the group is then a matter of permissions.
The first line contains the integer group identifier (GID).
Each line after that contains a user name
Management of the group is then a matter of permissions. To allow a user to add or remove group members, give them write access to that file.
Now, that simplistic system would work. But it has the drawback that people are editing the files by hand, and could potentiall mess things up for a large group of users if they fat finger something. Also, for a large group, you will often have to make a smaller group of users that exist solely to mange the larger group. This might be ok, or it might be way too much overhead.
A slightly more expressive system would look like this:
All files are owned by root, with permission 444Â (read only to all)
Top line of the file contains:
groupname:gid:coma seperated list of editors
after that each line is the uid of a group member.
vigroup: a program that works like visudo: it checks permissions prior to edit, edits the file and checks for valid structure prior to saving. As it is setuid, it is has the ability to modify the files in /etc/group.d
How about group nesting? Not too hard: a line in a groups configuration file could have an optional identifier, group: that indicates an entry is actually another group. Of course, this would complicate the calculation of group membership.
FreeIPA supports group nesting and delegation like this, albeit in LDAP, not using files. I’ll write more about it in another post.
This is an interesting idea, though I don’t think having the GID in a delegatable file is safe. It’d be easy for someone to accidentally or maliciously to duplicate a GID and gain inappropriate privileges.
Looks like you trying to reiplement OWL’s tcb: http://www.openwall.com/tcb/
If the “vigroup” program is setuid, it’s not really necessary to invent /etc/group.d – just let it manage the primary files.
More importantly, we _already have_ the concept of group administrators – see gshadow(5), and the setuid program – gpasswd(1).
Group nesting would be a much larger change…
Very good point, Ben. That would almost be a deal breaker. You’d have to keep the group ID separate from the group file. Yuck.
I’m not a fan of the group password approach. When someone logs in, we know who they are: authentication is complete. Group passwrods and an authorization question. The system has enough information to know how to handle it.
gpasswd(1) does not imply using the shared group password.