From: CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 3-JAN-1991 22:28:15.02 To: MRGATE::"ARISIA::EVERHART" CC: Subj: RE: ACLs and Directories Received: by crdgw1.ge.com (5.57/GE 1.80) id AA08956; Thu, 3 Jan 91 22:11:53 EST Message-Id: <9101040311.AA08956@crdgw1.ge.com> Received: From SCFD.NWC.NAVY.MIL by CRVAX.SRI.COM with TCP; Thu, 3 JAN 91 14:07:40 PST Date: 3 Jan 91 13:40:00 PDT From: "GSSF::GOPPELT" Subject: RE: ACLs and Directories To: "info-vax" Jerry Leichter writes : [...stuff deleted...] > If the point of adding the ACE's is to prevent users from making their file's > shareable - forget it. They can change the ACE's as easily as they change the > SOGW protection mask. The standard VMS access control system provides what is > called "discretionary control": The owner of an object has absolute control > over who he lets have access to it. What about the OPTIONS=HIDDEN+PROTECTED in the ACE? Example, add the following ACE to a scratch file using the EDIT/ACL editor (you'll see why I suggest a scratch file later) : (IDENTIFIER=NETWORK,OPTIONS=HIDDEN+PROTECTED,ACCESS=NONE) The HIDDEN option prevents a user from viewing the ACE unless they have the SECURITY privilege (you won't be able to see it with the DIR/SECURITY or SHOW ACL commands unless you have SECURITY enabled). PROTECTED means that the ACE will be preserved when an attempt is made to delete the entire ACL (i.e. SET ACL/DELETE will not delete a PROTECTED ACE, but SET ACL/DELETE/ACL=(specified-ace) will - or you can delete it in the EDIT/ACL editor.) Now I've found that I can only add a HIDDEN ACE with the EDIT/ACL editor, *not* with the SET ACL command. I can delete a HIDDEN ACE with the SET ACL/DELETE, but *not* with the EDIT/ACL. (I'm running VMS V5.4.) A PROTECTED ACE can be added, or deleted with the proper SET ACL or EDIT/ACL commands. But a HIDDEN+PROTECTED ACE can only be created with the EDIT/ACL and it *cannot* be deleted! SET ACL/DELETE doesn't do it, SET ACL/DELETE/ACL=(specified-ace) doesn't do it, EDIT/ACL and trying it from there doesn't do it either. In short, you can't get rid of it! (Now aren't you glad you tried this on a scratch file?) If you delete the file, obviously it goes away. So it would seem "possible" to add a security access measure, that the user cannot remove. But my advice? STAY AWAY FROM IT. I don't like the idea of a protection measure on files that CANNOT be removed. (You could COPY the file and delete the original, providing of course that the ACEs aren't being propagated by a subdirectory with the OPTIONS=DEFAULT set. I can see a very troublesome configuration here...) Jerry's advice of : > Create a comprehensive security policy. Put IN WRITING what the goals of the > policy are: Who is to be allowed access to what, who is to be allowed to > control what. Make sure everyone involved understands the policy and is > satisfied with it. is excellent. dave ------------------------------------------------------------------------------ |David S. Goppelt |Internet: goppelt%gssf.decnet@nwc.navy.mil | |Naval Weapons Center | goppelt%gssf.decnet@26.3.0.85 | |China Lake, CA 93555 USA|Or: goppelt@nwc.navy.mil | |(619) 939-5023 av 437-5023|-------------------------------------------------| | |"I'm different than other people - pain hurts me"| ------------------------------------------------------------------------------