Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!uunet!brunix!doorknob!da From: da@cs.brown.edu (David Ascher) Newsgroups: comp.unix.admin Subject: user-defined groups Message-ID: Date: 20 Mar 91 04:20:07 GMT Article-I.D.: igor.DA.91Mar19232007 Sender: news@brunix.UUCP Organization: Department of Computer Science, Brown University Lines: 41 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@brownvm.Brown.EDU (Internet) == UUCP: uunet!brunix!da == Bitnet: dascher@brownvm