Fine points of ACL conversion
rsharpe at ns.aus.com
Wed Jul 31 09:24:01 GMT 2002
I am trying to clear up the fine points if ACL in Windows and POSIX.
Under windows, user asks for RPERM, and the ACL code walks the ACEs. I am
under the impression that it does:
1. If it encounters a DENY (negative) ACE that denies any of the bits
requested, it denies access.
2. If it encounters ALLOW ACLs that allows any of the bits, but not all,
it continues? Is this true. Does it accumulate permission bits until the
requested bits are available and then stop? If a DENY appears after an ACE
that allows some bits, but not all, presumably, it denies access. So order
is very important. However, does it accumulate perms.
Under Posix ACLs, the standard USER and GROUP entries are processed first,
and if the requestor matches one of those, request is allowed if all RPERM
bits are present, else denied. If user does not match USER or GROUP, walk
the remaining ACEs looking for a match that contains all the requested
bits and check the MASK as soon as one is found that matches. However,
PERM bits are not accumulated, so there might be ACEs on the list, that
combined contain all the RPERMs, but individually don't, so the user will
be denied. If none of the normal ACEs match, the Everyone ACE is checked.
Lastly, the MASK is checked and if any bits in the RPERM are not present
in the MASK, access is denied.
Is this correct?
Richard Sharpe, rsharpe at ns.aus.com, rsharpe at samba.org,
sharpe at ethereal.com
More information about the samba-technical