da@cs.brown.edu (David Ascher) (03/20/91)
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
rickert@mp.cs.niu.edu (Neil Rickert) (03/20/91)
In article <DA.91Mar19232007@igor.cs.brown.edu> da@cs.brown.edu (David Ascher) writes: >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. >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. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
mqh@theory.tn.cornell.edu (Mike Hojnowski) (03/21/91)
> > 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. I disagree. We have a very similar need here. We will have a large system with >2000 userids. We may also eventually have a fleet of RS/6000's with a common uid space. Root privileges on these systems might be limited to our adminstrative group. 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.
da@cs.brown.edu (David Ascher) (03/21/91)
In article <1991Mar20.045739.27136@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: In article <DA.91Mar19232007@igor.cs.brown.edu> da@cs.brown.edu (David Ascher) writes: >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 == Internet: dascher@brownvm.Brown.EDU (Internet) == UUCP: uunet!brunix!da == Bitnet: dascher@brownvm