Group Delegation in Unix

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.

6 thoughts on “Group Delegation in Unix

  1. 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.

  2. 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…

  3. 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.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.