Path: utzoo!utgpu!watmath!clyde!att!osu-cis!killer!ames!pasteur!ucbvax!CAEN.ENGIN.UMICH.EDU!markg
From: markg@CAEN.ENGIN.UMICH.EDU (Mark Giuffrida)
Newsgroups: comp.sys.apollo
Subject: acls
Message-ID: <40c3242c8.0017b5e@caen.engin.umich.edu>
Date: 9 Jan 89 14:45:41 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 36


	> 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