user-defined groups

David Ascher da at cs.brown.edu
Wed Mar 20 14:20:07 AEST 1991


One of the biggest problems in my mind with the Un*x uid/gid/chmod
system is that it doesn't scale up very well.  On a large system with
hundreds of users, it is administratively inconvenient to allow for
flexible groups.  A project manager cannot create a group for its
project members without having root access or having the sysadmin do
it.  This allows for some enhanced security in theory, but in reality
I suspect that when people want to share files, they tend to go
overboard in the wrong direction: give _everyone_ read access.

A more flexible group management scheme seems needed in the world of
NFS-mounted networks of workstations with hundreds of users.  I'd like
to know what, if anything, is wrong with the following scheme:

1.  A group manager application program (called gappl, say), which
accepts "Applications" for group creation.  Through this mechanism,
Kim A. User can apply for a group, giving herself and her colleague
Tom Z. Kollyg co-moderator status.  The program (or "root") would
decide if the group is worthy of existence according to local
policies, and if so, register their uid's as group owners.

2.  A group manager program (gadmin?) which would accept commands from
group administrators, and automate adding new uid's to a given group.
This is where the security needs to be tweaked to the maximum so that
aliases and other special id's can't be added.  It would probably be a
good idea to have the users themselves confirm that they wish to
belong to this group.

The second program could easily be a daemon which would modify the
/etc/groups file...  

This scheme of system administration works effectively on other OS's
-- is there any inherent reason why a little software can't complement
the OS in this case?

just curious...

--
== David Ascher -- Brown University, Providence RI 02912 
==  Internet:      dascher at brownvm.Brown.EDU (Internet)
==  UUCP:          uunet!brunix!da
==  Bitnet:        dascher at brownvm



More information about the Comp.unix.admin mailing list