tencati@VLSI.JPL.NASA.GOV (PLS REPLY TO TENCATI@GPVAX.JPL.NASA.GOV) (07/14/88)
I just heard a disturbing rumor. If true, it explains why a lot of people
are confused about WHEN an ACL is checked.
The rumor is that if you have an ACE that reads:
(Identifier=Something,Access=None)
That the NONE qualifier does NOT mean "deny access", it merely instructs
the filesystem to stop processing the ACL, and proceed on to check the
file protection mask. This means that if I have a file protected with
the mask (s:rwed,o:rwed,g:re,w:r) that no ACL is going to prevent access
to this file, and that in order for the ACL to behave in the "expected"
manner, that the file must first be locked down with the UIC-based protection.
The thing I find disturbing about this is that I was under the (mistaken?)
opinion that if you said ACCESS=NONE in an ACE, that you were instructing
the filesystem to DENY access to the file, when instead the file should
be given the most extreme UIC-based protection mask, and the ACE is used
only to GRANT access to the file (..guess that's why it's called an "Access"
Control Entry, huh?..)
Anyway, this explains why some people are confused about when the ACL is
checked. If your UIC-based protection would allow access, then the ACL is
going to be ineffective, and it would appear that it was not "consulted"
during a file access you thought should have failed.
Can anyone confirm or deny the rumor that "Access=None" does not mean
"DENY access"?
Ron Tencati
Jet Propulsion Laboratory
Pasadena, Ca. 91109
TENCATI@GPVAX.JPL.NASA.GOV
JPLGP::TENCATI (SPAN)LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) (07/20/88)
I just heard a disturbing rumor. If true, it explains why a lot of people are confused about WHEN an ACL is checked. The rumor is that if you have an ACE that reads: (Identifier=Something,Access=None) That the NONE qualifier does NOT mean "deny access", it merely instructs the filesystem to stop processing the ACL, and proceed on to check the file protection mask. This means that if I have a file protected with the mask (s:rwed,o:rwed,g:re,w:r) that no ACL is going to prevent access to this file, and that in order for the ACL to behave in the "expected" manner, that the file must first be locked down with the UIC-based protection. The thing I find disturbing about this is that I was under the (mistaken?) opinion that if you said ACCESS=NONE in an ACE, that you were instructing the filesystem to DENY access to the file, when instead the file should be given the most extreme UIC-based protection mask, and the ACE is used only to GRANT access to the file (..guess that's why it's called an "Access" Control Entry, huh?..) Anyway, this explains why some people are confused about when the ACL is checked. If your UIC-based protection would allow access, then the ACL is going to be ineffective, and it would appear that it was not "consulted" during a file access you thought should have failed. Can anyone confirm or deny the rumor that "Access=None" does not mean "DENY access"? Rather than trying to track down, deny, or confirm rumors, why not check the documentation? The VMS Guide to System Security contains a "Flowchart of Access Request Evalua- tion" (for the V4.2 doc set, the only one I have handy, it's Figure 4-4 on page 4-45). This four-page (!) flowchart will tell you EXACTLY what is checked, in what order. (Well, that's not quite true; you have to understand the context. For example, the flowchart has sequential boxes that test whether "the ACL grants access" or "the ACL denies access". This makes it look like the entire ACL is first scanned for an ACE granting access, then for an ACE denying it. In fact, the documentation makes clear (Section 4.3.4) that a single scan of the ACL is made, and the first match found is the only one used.) I should probably NOT answer your specific question, in order to encourage you to check the documentation; but... If we follow the flowchart through, we see that there IS an ACE, and it denies access. This sends us to label BB. The flowchart here gets messy. For objects with non-0 owners (most things), the owner UIC is allowed access if the OWNER field of the access mask allows it; or a system UIC (or process with SYSPRV or process in the same group as the object's owner and with GRPPRV) is allowed access if the SYSTEM field of the access mask allows it. The GROUP and WORLD fields of the access mask are ignored. (There are additional complications in the flowchart to deal with various privileges the accessor might have; and it is SIMPLIFIED since it ignores alarm ACE's.) Please take the above text with a grain of salt. The definitive reference is the documentation (well, the really DEFINITIVE one is the code!); I may have transcribed it incorrectly. -- Jerry
MCGUIRE@GRIN1.BITNET ("The Sysco Kid ", McGuire,Ed) (07/21/88)
> Date: Thursday, July 14, 1988 at 8:24 am pdt > From: PLS REPLY TO TENCATI@GPVAX.JPL.NASA.GOV <tencati@VLSI.JPL.NASA.GOV> > Subj: ACL behavior > > Can anyone confirm or deny the rumor that "Access=None" does not mean > "DENY access"? In general, ACCESS=NONE denies access. There are a few exceptions. ACCESS=NONE is ignored and the protection code is checked instead, if the requester is in one or more of the following categories. - owns the object - is in the same group as the object's owner and has GRPPRV privilege - has SYSPRV privilege - has a system UIC BYPASS (or READALL for a read-only request) grants access regardless of ACL or protection code. See the flowchart on p. 4-45--4-48 of the Guide to VAX/VMS System Security, July 1985. Ed
MNK@DRACO.HAC.COM (Michael N. Kimura) (07/22/88)
> I just heard a disturbing rumor. If true, it explains why a lot of people > are confused about WHEN an ACL is checked. > > The rumor is that if you have an ACE that reads: > > (Identifier=Something,Access=None) > > That the NONE qualifier does NOT mean "deny access", it merely instructs > the filesystem to stop processing the ACL, and proceed on to check the > file protection mask. [incorrect information deleted] > Can anyone confirm or deny the rumor that "Access=None" does not mean > "DENY access"? This NOT true. If you deny access to an object (file) by indentifier than anyone possesing that identifier is indeed denied access to the object (file) no matter what the file protection mask is. The only exceptions to this are: 1) You are the owner of the file then the owner field is used 2) You are in the same group and you have GRPPRV privilege then the system field of protection mask is used. 3) You have SYSPRV privilege or your UIC is a SYSTEM UIC then the system field of protection mask is used. 4) You have BYPASS privilege then access is ALWAYS granted. 5) You have READALL privilege and the access is READ or CONTROL. See figure 4-4 "Flowchart of Access Request Evaluation" on pages 4-45 through 4-48 of the Guide to VAX/VMS System Security. Michael Kimura Arpanet: mnk%draco@hac2arpa.hac.com BITNET: mnk.draco.hac.com Phone: (213) 615-9775