Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Unix Operating Systems Software

Nested Groups on Unix? 19

Posted by Cliff from the better-access-control dept.
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?
This discussion has been archived. No new comments can be posted.

Nested Groups on Unix? More

Nested Groups on Unix?

Comments Filter:

  • Maybe this is what you need... (Score:1)

    by Anonymous Coward
    Active Directory uses objects to represent network resources such as users, groups, machines, devices, and applications. It uses containers to represent organizations, such as the marketing department, or collections of related objects, such as printers. It organizes information in a tree structure made up of these objects and containers, similar to the way the Windows operating system uses folders and files to organize information on a computer.

    In addition, Active Directory manages the relationships among objects and containers to provide a single, centralized, comprehensive view. This makes resources easier to find, manage, and use in a highly distributed network. The Active Directory hierarchy is flexible and configurable, so organizations can organize resources in a way that optimizes their usability and manageability.

    Containers are used to represent collections of users, machines, devices, and applications. Containers can be nested (created one-inside-the-other) to reflect accurately the company's organizational structure. In this case, marketing and personnel organization containers represent those respective departments, and their relationship to one another, within the company. Grouping objects in the directory lets administrators manage objects on a macro-level (as collections) rather than one-by-one. This increases management efficiency and accuracy while letting organizations align network management with their business processes.

    ---
    Windows 2000: Buy into stability today.

  • A script that would combine all the names of the people in the nests and spit them out in flat groups would be perfect. I'd just create a script to read from your nested group file "/etc/mygroups" and spit the new groups into the regular ol "/etc/group".
  • Didn't he already say he was considering LDAP???
  • He's not really a troll. To my understanding, a directory (like AD, not that I'd want to use it) is the perfect framework for the sort of granularity this guy is asking for. We have Novell here, and the sort of stuff he's asking for is the heart of simplicity.

  • Hmmm... I think I've heard all this some time before... let's see... 1996... Novell...

    Oh, yeah, just this little product known as Novell Directory Services. Funny, I would have described NDS almost exactly like you did this... Microsoft "Active Directory" thing.


    -Matthead

  • Perl? Oh hell yeah. Perl is my (and yours, right?) language of choice for text file parsing.

    Why would rewriting system code be necessary? If you have a `vigroup' like you have `vipw', what's so difficult? That sounds to me like "the Right Way to do it."


    -Matthead

  • Neither do I need intersection,

    d: @students * @faculty

    is expressible with union and complement:

    d: !(!@students + !@faculty)

    This is the question of whether you want to go for expressiveness, or if you should only implement a minimal core of operations ...
  • Not a troll eh? Look at his other 'All linux users are criminals' post...
  • I don't have the mod points, so I'm forced to post to add my agreement here. If it's more your style, something perly, or whatnot might be better, but either way it's still the simplest solution. Doing it the Right Way would require tracking down and rewritting the neccessary bits of system code, definately a non-trivial task.
  • What I meant was that if you didn't go with vigroup you're other option would be to rewrite the system code to handle a new format of the /etc/groups file. While the script may be simpler, and require far less effort, it's a bit of hack...
  • You don't need delete...

    d: @students + @faculty - bleahy

    could be expresed with (assuming each user is a set of herself alone):

    d: (@students + @faculty) * (!bleahy)
  • I think that this makes an excellent argument for making it a preprocessor, that is run when groups has changed, or when a user is added (in case there are rules like:[ x: !(@students) ])

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

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

  • 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.)


    --

  • 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 (Score:3)

    by jantangring ( 78094 ) <gnirreNO@SPAMgmail.com> on Wednesday December 13, 2000 @12:45AM (#563663) Homepage Journal
    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 (Score:3)

    by shippo ( 166521 ) on Wednesday December 13, 2000 @04:13AM (#563664)
    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 (Score:4)

    by alannon ( 54117 ) on Tuesday December 12, 2000 @06:30PM (#563665)
    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.

Slashdot Top Deals

I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"

Close