4 March 1991
Paul A. Karger
Open Software Foundation
11 Cambridge Center
Cambridge, MA 02142 USA
+1 617 621 8994
The access control list designs coming out of the X.500 and POSIX 1003.6 standards committees conflict in-certain ways. As both are intended to become ISO standards and both will likely be used in the same computer system, it would be highly desirable if one were at least a subset of the other. I have not fully studied the X.500 proposals, but after a superficial reading, I see the following conflicts:
a) POSIX ACLs specify that if a process is a member of multiple groups and any of the groups has access to an object, then the process gets access. (The rights are OR-ed together.) X.500 ACLs specify that if a user matches multiple subtree user classes, then the user gets access only if ail the subtree user classes have access. (The rights are AND-ed together.) This is a direct conflict between the proposed standards. POSIX rationalizes its choice, because in Berkeley UNIX, a process may turn its group memberships on and off and thus could always get access, regardless.Other than these two conflicts, POSIX ACLs appear to be subsets of X.500 ACLs. However, I have not fully understood X.500 ACLs, so there may be other problems. In particular, I have not seen how default ACLs work in X.500.
b) POSIX ACLs have the concept of a MASK_OBJ that is logically anded wirh all access rights granted to any process by any ACL entry for a named user or group other than the owner of the object or the reserved entry OTHER_OBJ for all other processes not otherwise named. There is no corresponding concept of MASK_OBJ in X.500. This is understandable, since MASK_OBJ exists only for compatibility with the old UNIX owner/group/other protection scheme.
I don't propose a solution at this time. I propose that
the POSIX 1003.6 committee and the X.500 committee need to communicate
with one another to attempt to resolve the incompatibilities.
It would be highly desirable if POSIX ACLs were a proper subset of X.500
ACLs, as that would make the user interface much simpler to understand.
The European Security Evaluation Criteria (ITSEC) specifically call for
ease of secure use as an evaluation criteria, and such a subsetting relationship
would definitely improve ease of secure use.