Nested Groups on Unix?

Claus Färber asks: "Is there an easy way to add nested groups (i.e. groups that contain or import user lists from other groups) to Unix account management? While you can manually add all users of one group to the other, it is very hard not to forget to remove or add users to all groups. I already thought of patching NIS modules, providing a PAM module (but will this work with Samba and NFS?) or switching to LDAP (but RFC 2307 does not allow nested groups either...). Has anyone already done this, or are there better ideas?" I've always wondered about this issue as well. Wouldn't extending the /etc/group file to handle nested groups, and the ability to exclude users from groups, be a way of implementing a more finely grained permissions system for Unix?

To understand the advantages of nested groups, I'll use the following example:

Typically, unix groups look like the following:

a: user1, user2, user3
b: user3, user4, user5
c: user6, user7, user8

Now if I want to create a group "d" that is comprised of groups "b" and "c" under most Unices, then you'd add the following line to /etc/groups:

d: user3, user4, user5, user6, user7, user8

Now if I were allowed to nest groups, I could just do:

d: @b, @c

Where the "@" means 'import names from group "b"'.

The advantage of the latter system is that you can add users to group "b" and "c" and not have to maintain the group "d" line as well. Another useful extension would be the exclusion operator, so that if I wanted to remove a specific user from a group (to insure said user isn't included, even if he's a member of an included group) I could do the following:

e: !user1, @a, @b

Instead of manually creating a new list of individual user names:

e: user2, user3, user4, user5, user6

Now you can do something similar to this using NIS and netgroups for large networks, but this feature seems to be particularly useful for the single-machine-large-userbase without the hassle of configuring another service. Would you admins out there find this to be a useful feature? If so, how difficult would it be to modify existing Unix systems to handle these extensions? If not, what reasons can you give as to why future Unix systems should not implement this feature?

Comments

While you're at it

[jantangring]

These are set operations you are suggesting for group membership. While you're at it, add the other set operations too.

A group is a set, and users are members. Let's see, the only built-in is a constructor, using users as operands.

<I>d: user3, user4, user5</I>

You already added union, using both groups and single members as operands.

d: @b, @c

You want to combine, adding up users and groups to define a new group.:

d: @b, @c, user9

Comma is overloaded, used both as a union-operator, and an insert-member" operator. I don't see a problem with that, you use @ to tell it's a group-name, so we won't be able to use @ as first char in a group name, without an escaping notation (maye @ isn't allowed in group names already).

You have a delete-member operation:

e: !user1, @a, @b

the problem is the exclamation leads my mind to the complement operation, meaning you add all members except user1 to the group. I think we would want the complement operation, ie to make a group for all users who are not members of group a:

e: ! @a

So, for delete-member (and the set-level equivalent difference operation= lets use a minus. To define as group e, all members of a and b, except user1 and members of c:

e: @a, @b - user1 - @c

Finally, we want intersection. To define e as all users who are members of both a and b:

e: @a * @b

Maybe, beeing so close to standard set notation now, we should loose the comma, and use plus as the union-operator

<tt>d: @b + @c + user9</tt>

We also need parenthesise for precedence

<tt>d: @b * (@c + user9)</tt>

Lists under StreetTalk

[shippo]

This sounds a bit like the lists available under StreetTalk, Banyan's directory services that have been around since the late 1980's. I supported this technolgy for many years, and there were a couple of interesting problems associated with such structures.

StreetTalk names were in the format x@y@z, where y was confusingly called a group, and z the organisation. StreetTalk had 4 main data-item types, users, nicknames (a pointer to another streettalk item), services (a process) and lists. Lists could contain one or more instances of the other, including other lists, and also wildcard patterns which only matched users and services.

The problem was with list evaluation. If a list pointed to other lists these searches could be time consuming, particularly if one of the lists to be searched was remote.

It was time consuming to search lists, particularly if users were not in the list (a common occurance in access permissions). We'd often get the case where administrators could access resources immediately, but normal users would have 40 second delays in getting to their data, as a list of valid administrators had to be searched in full before the user could be validated. I even had one factory in Scotland which made remote StreetTalk calls to the head office in Ohio whenever a non-admistrative user attempted to open a local file.

I used to spend a large amount of time optimising the use of lists to be as simple as possible, usually replacing them with wildcards. The problem was that those designing such list mechanisms didn't understand the underlying technology.

I'd want to avoid using a structure as proposed due to these, as a lookup will need to be performed everytime one of the groups is evaluated. This will take some time. Best bet is to have some mechanism for generating the new /etc/groups file on the fly.

Preprocessor

[alannon]

Maybe I'm being a little bit naive, but wouldn't it be possible to simply write a preprocessor that followed your rules and spat out a completed /etc/groups file as a result? Then your solution would be portable and would require no new additions to any other systems.