Very Computer

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

==  UUCP:          uunet!brunix!da

Quote:>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:

--
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

  Northern Illinois Univ.
  DeKalb, IL 60115                                   +1-815-753-6940

   >I suspect that when people want to share files, they tend to go
   >overboard in the wrong direction: give _everyone_ read access.

    Why is that going overboard.  Most files do not contain sensitive information,
   so there is no reason for them not to be publically readable.

In such cases, I agree, this isn't going overboard.  But the whole
concept of rights assumes that some files need to be protected.  I am
looking for opportunities to make this more flexible, that is all.
What's more, whereas most files do not contain sensitive information,
there are lots of executables which shouldn't be run by people who
don't know what they do...

   >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:

    For the kind of joint project you are talking about, I don't think your
   world of 'networks of workstations with hundreds of users' is realistic.
   Try a world of 'networks of hundreds of workstations, each with one or two
   principle users.'  For this type of setup, where the principle users
   probably have root access to their own workstation, your solution is
   far too complex.

Well, I was actually thinking of something like the Brown Computer
Science network, where there are a couple of hundred workstations all
NFS-linked, with say, >300 users, but only a few people (sysadmins)
have root access.  This setup is quite appropriate in a system where
users don't have "their" workstation, but can use any one of hundreds.

So:  1.  Why would someone not like the idea of user-defined groups?
     2.  What are the security flaws in the system I have described?

--
== David Ascher -- Brown University, Providence RI 02912

==  UUCP:          uunet!brunix!da

Quote:

> For the kind of joint project you are talking about, I don't think your
>world of 'networks of workstations with hundreds of users' is realistic.
>Try a world of 'networks of hundreds of workstations, each with one or two
>principle users.'  For this type of setup, where the principle users
>probably have root access to their own workstation, your solution is
>far too complex.

It is always desirable to be able to distribute responsibility away from
one system administrator with the keys to the city.  We've come up with
a solution using "expect" which allows us to have a group administrator
for certain groups.  Our solution still requires that a root user set up
the administrator, and the group.