From: SMTP%"lauri@elwing.fnal.gov" 30-JUL-1993 08:29:58.98 To: EVERHART CC: Subj: Re: How do you do manage project XYZ for users a, b and c? From: lauri@fndcd.fnal.gov (Laurelin of Middle Earth) X-Newsgroups: comp.os.vms Subject: Re: How do you do manage project XYZ for users a, b and c? Date: 28 Jul 1993 16:27:33 GMT Organization: Fermi National Accelerator Lab Lines: 76 Message-Id: <2369dl$97a@fnnews.fnal.gov> Reply-To: lauri@elwing.fnal.gov Nntp-Posting-Host: dcd00.fnal.gov To: Info-VAX@kl.sri.com X-Gateway-Source-Info: USENET In article , ratel@ireq.hydro.qc.ca (Gilles Ratel 8720) asks how to manage project accounts: >Hello, > > Suppose project XYZ and users a, b and c with account A, B and C. > > Users a, b and c work on project XYZ. > > Question: How do you do manage project XYZ for a, b and c ? > - a, b and c: create,delete files and directories > - No new account XYZ (i.e. no new password) > - facilty for add or cancel new user d, with accound D > > This is possible only with access control list (ACL) ? We have been doing this for several years, and yes we do it with ACL's. The steps we take are: 1) Create the project rights identifier: $ MCR AUTHORIZE UAF> ADD/ID XYZ_PRJ/ATTRIBUTES=(RESOURCE,NODYNAMIC) The RESOURCE attribute means that you can charge resources (like diskquota) to the identifier. 2) Grant disk quota to the identifier. Create the project directory, owned by the identifier, and set up the initial ACL for the directory file. $ MCR DISKQUOTA DISKQ> USE project-disk DISKQ> ADD XYZ_PRJ [/PERMQUOTA=nnn] [/OVERDRAFT=mmm] $ CREATE/DIRECTORY project-disk:[XYZ_PRJ] - /OWNER=XYZ_PRJ - /PROTECTION=(SY:RWED,OW:RWED,GR:RE,WO:RE) $ SET ACL/ACL=(ID=XYZ_PRJ,OPTIONS=DEFAULT,ACCESS=R+W+E+D+C) - project-disk:[000000]XYZ_PRJ.DIR $ SET ACL/ACL=(ID=XYZ_PRJ, ACCESS=R+W+E+D+C) - project-disk:[000000]XYZ_PRJ.DIR The first ACL above does nothing to the XYZ_PRJ.DIR file itself, it merely propogates to all files created within the directory. The second ACL grants to holders of the XYZ_PRJ identifier the ability to create files, look at files, delete files, do wild-card DIRECTORY commands, etc., within the [XYZ_PRJ] directory. 3) Grant the identifier to the appropriate users. $ MCR AUTHORIZE UAF> GRANT/ID XYZ_PRJ A UAF> GRANT/ID XYZ_PRJ B UAF> GRANT/ID XYZ_PRJ C The order you enter the above commands will be preserved when you UAF> SHOW/ID/FULL XYZ_PRJ so we tend to use it as an unofficial indicator of "who the boss is". That is, if A is granted the identifier first, then probably A is the person who is in charge of this identifier. If somebody new asks for the identifier and we aren't sure if they should get it, we ask A. 4) The XYZ_PRJ users may sometimes have difficulty DELETEing a file that they themselves created, even though anybody else with the XYZ_PRJ can delete it on their behalf. (This is due to a user-specific ACE that VMS puts on newly-created files whether or not you want it; depending on the user's default protection setting, it may or may not include DELETE access for THAT particular user, who sits at the top of the ACL list). Teach your users to $ SET ACL/DEFAULT file.ext;N when they need to delete a file and cannot due to "insufficient privilege or file protection violation". Also teach your users do $ DIRECTORY/SECURITY (so they see the ACL list as well as UIC-based security settings). (I hear that this user-specific ACE may disappear, or at least be optional, in future versions). -- lauri ----------------------------------------------------------------------------- | Laurelin Loebel "All that is gold does not glitter, | | lauri@elwing.fnal.gov Not all those who wander are lost..." - JRRT | |...they don't generally like what i say anyway, so i don't speak for them... | -----------------------------------------------------------------------------