X.500 vs. POSIX ACLs

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.

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.

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.

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.