dennis@peanuts.nosc.mil (Dennis Cottel) (01/07/89)
But ACLs can't do groups nicely either. Suppose you want a group of people to have read/write access to a project directory. So before you start you set the ACLs at the root of the directory to explicitly allow access for all those users in the group. But if a new person comes along later, you have to add to the ACLs for every file in the tree. And automating this is not easy because you can't just "edacl -a newuser -user tree/... -all" because permissions will vary on files within the tree: some are executable, RCS files are read only, etc. Of course, you could simply set the ACLs to use %.project as the userid, but then a person has to log in differently depending on what s/he wants to do. Ugh. Too bad ACLs don't contain a group concept as well. Dennis Cottel Naval Ocean Systems Center, San Diego, CA 92152 (619) 553-1645 dennis@nosc.MIL sdcsvax!noscvax!dennis
crgabb@sdrc.UUCP (Rob Gabbard) (01/08/89)
In article <856@nosc.NOSC.MIL>, dennis@peanuts.nosc.mil (Dennis Cottel) writes: > But ACLs can't do groups nicely either. Suppose you want a group of > people to have read/write access to a project directory. So before At Sr10 Apollo has fully implemented the Berkley Project List concept. If someone is logged in as joe.research and wants access to a file whose group is marketing he will be given access if he is allowed to be a member of the marketing group (i.e. if he is included in marketing's membership list in the registry). This pertains to Domain/OS BSD4.3 and can be used for Domain/OS Aegis and Sys VR3 if the PROJLIST environment variable is set to true. With edrgy you can do some fancy things like restricting a group from being in a project list (e.g. if that group is not the accounts primary group it will not appear in his project list even if the user is a member of that group). They implemented a semi-form of Project Lists at SR9.5 Domain/IX but it didn't work too well. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rob Gabbard (uunet!sdrc!crgabb) _ /| Workstation Systems Programmer \'o.O' Structural Dynamics Research Corporation =(___)= U =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
sharp@.ucalgary.ca (Maurice Sharp) (01/09/89)
Hiya, In article <856@nosc.NOSC.MIL>, dennis@peanuts.nosc.mil (Dennis Cottel) writes: > But ACLs can't do groups nicely either. Suppose you want a group of > people to have read/write access to a project directory. So before > you start you set the ACLs at the root of the directory to explicitly > allow access for all those users in the group. But if a new person The idea of a project is NOT to set acls for each individual member. As susggested below, the %.project is the ACL to use. > Of course, you could simply set the ACLs to use %.project as the > userid, but then a person has to log in differently depending on what > s/he wants to do. Ugh. I am not sure about pre SR10.x, but now you certainly do not have to log is as fred.proj1 to work on proj1. With the PROJLIST idea, you can access any files that belong to any project that you are a member of. In fact, at SR10.x, it is a PGO (person, group, organization) instead of a PPO. > Too bad ACLs don't contain a group concept as well. I suggest that you upgrade to SR10.1, so that you can get the functionality. Maurice sharp@ksi.cpsc.UCalgary.CA sharp@calgary.CDN (ean)
markg@CAEN.ENGIN.UMICH.EDU (Mark Giuffrida) (01/09/89)
> But ACLs can't do groups nicely either. Suppose you want a group of > people to have read/write access to a project directory. So before > you start you set the ACLs at the root of the directory to explicitly > allow access for all those users in the group. But if a new person > comes along later, you have to add to the ACLs for every file in the > tree. And automating this is not easy because you can't just "edacl > -a newuser -user tree/... -all" because permissions will vary on files > within the tree: some are executable, RCS files are read only, etc. > > Of course, you could simply set the ACLs to use %.project as the > userid, but then a person has to log in differently depending on what > s/he wants to do. Ugh. > > Too bad ACLs don't contain a group concept as well. This is not correct. As a one time operation you acl the tree for %.project. Although the mechanism is conceptially better designed in sr10, it also works fine on sr9.* nodes as well. In sr10, you can simply make a user part of that project group (in fact, you can also give a normal user rights to modify any particular group list). And that is all. To add a new user to the group, it is a registry operation (1 command) and not a reacl for the entire tree. In sr9.* it works in a similar manner. You must give that person another login that specifically uses that project. Now if you have set up your node correctly and set the environment variable PROJLIST true in the startup file, it doesn't matter which of the projects you initially log into, the os knows about all the groups you are in and will grant you proper access. In other words, if I have 2 accounts markg.users.none markg.newgroup.none I can log in as markg.users.none and have access to all the %.newgroup.% files assuming the PROJLIST environment variable is true. Mark Giuffrida University of Michigan markg@caen.engin.umich.edu
dennis@peanuts.nosc.mil (Dennis Cottel) (01/11/89)
Thanks, folks, for the information (education) on PROJLIST. I didn't remember seeing this in the documentation, so knowing what to look for, I went perusing my SR9.x manuals. The only index reference I could find for PROJLIST is on page 1-9 of the "Domain/IX User's Guide" where it is mentioned in a table of environment variables, but doesn't explain what it does (to someone who doesn't already know). Sigh. However, in the SR10 manual (provided early to all Mentor sites--nice job, Mentor) called "Managing Aegis System Software" I found PROJLIST in the index. (Sorted wrong, unfortunately, because capitalized letters are sorted before lower case.) The explanation here is clear, though, so maybe the documents are getting better. Dennis Cottel Naval Ocean Systems Center, San Diego, CA 92152 (619) 553-1645 dennis@nosc.MIL sdcsvax!noscvax!dennis