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

m4 your group file perhaps

[embobo]

One way to manually do it would be to use m4 macros in your group file and create a script "vigroup" (ala vipw) that opens the /etc/group.m4 file for editing and then process it with m4 into /etc/group afterward.

Corporate solution

[CoderDevo]

If the nested groups under Unix problem needs to be solved for all systems in a corporation, then let me suggest Conrol-SA from BMC Software. It provides one GUI console to manage users and groups for all systems in the enterprise.

Control-SA uses an entity called a Job Code to associate the groups a user needs to be a member of to perform his/her job. These groups can even be on different systems. When a new employee joins the company, you drag and drop the Job Code onto the User. All user accounts for that person are created on all systems they need access to based on the groups to which the Job Code is connected.

In fact, Control-SA even catches and displays changes to user accounts if a system administrator modifies the accounts without using the Control-SA GUI.

I'm sorry for the plug, but I spend all of my time working with this stuff and I love it.

Re:Lists under StreetTalk

[StandardDeviant]

Ouch, that streettalk stuff does sound painful. :-)

Anyway, the solution to the evaluation problem lies in what some other people have already posted, namely you make a seperate file with a custom grammar, and a perl|shell|whatever script that parses that and re-writes the real groups file as needed so it is just a static, normal format file. (Analogous to the way that the front page to slahdot is static, rewritten once every ten or so minutes by a daemon.)

--

Trolles Be Amongst Us Bretheren!

[StandardDeviant]

Thou art a Trolle, ye Foul Beaste! Get thine Asse Backe Unter Thine Foule Bridge, lest I Whaule Ooop and Kicke Thine Bootae!

--

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.