Path: utzoo!utgpu!watmath!clyde!att!alberta!calgary!!sharp
From: sharp@.ucalgary.ca (Maurice Sharp)
Newsgroups: comp.sys.apollo
Subject: Re: ACLs
Summary: Correcting an misconception
Message-ID: <460@cs-spool.calgary.UUCP>
Date: 9 Jan 89 09:16:11 GMT
References: <40b47aa32.000bf2e@caen.engin.umich.edu> <856@nosc.NOSC.MIL>
Sender: news@calgary.UUCP
Lines: 30

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)