Previous section.

DCE 1.1: Authentication and Security Services
Copyright © 1997 The Open Group

Access Control Lists (ACLs)

This chapter specifies the ACLs supported by DCE. It consists entirely of the static (data) properties of ACLs- the dynamic (programmatic) properties of ACLs are dealt with in ACL Managers . For generalities on ACLs, see Access Control Lists (ACLs) .

Data Types

This section defines (in IDL/NDR) the data types associated with ACLs.

Interface UUID for ACLs

The interface UUID for the ACL information specified in this chapter (and also in ACL Managers , is given by the following:

[ uuid(47AEE3EA-F000-0000-0D00-01DC6C000000) ] interface sec_acl_base

ACLE Types

ACL entry (ACLE) types are represented by the sec_acl_entry_type_t data type, which is defined as follows (comments indicate the values and the "colloquial" names of each type, as used in Access Control Lists (ACLs) ):

typedef enum { sec_acl_e_type_user_obj, /* 0 -- USER_OBJ or UO */ sec_acl_e_type_group_obj, /* 1 -- GROUP_OBJ or GO */ sec_acl_e_type_other_obj, /* 2 -- OTHER_OBJ or O */ sec_acl_e_type_user, /* 3 -- USER or U */ sec_acl_e_type_group, /* 4 -- GROUP or G */ sec_acl_e_type_mask_obj, /* 5 -- MASK_OBJ or M */ sec_acl_e_type_foreign_user, /* 6 -- FOREIGN_USER or FU */ sec_acl_e_type_foreign_group, /* 7 -- FOREIGN_GROUP or FG */ sec_acl_e_type_foreign_other, /* 8 -- FOREIGN_OTHER or FO */ sec_acl_e_type_unauthenticated, /* 9 -- UNAUTHENTICATED or UN */ sec_acl_e_type_extended, /* 10 -- EXTENDED or E */ sec_acl_e_type_any_other, /* 11 -- ANY_OTHER or AO */ sec_acl_e_type_user_obj_deleg, /* 12 -- USER_OBJ_DEL or UOD */ sec_acl_e_type_user_deleg, /* 13 -- USER_DEL or UD */ sec_acl_e_type_for_user_deleg, /* 14 -- FOREIGN_USER_DEL or FUD */ sec_acl_e_type_group_obj_deleg, /* 15 -- GROUP_OBJ_DEL or GOD */ sec_acl_e_type_group_deleg, /* 16 -- GROUP_DEL or GD */ sec_acl_e_type_for_group_deleg, /* 17 -- FOREIGN_GROUP_DEL or FGD */ sec_acl_e_type_other_obj_deleg, /* 18 -- OTHER_OBJ_DEL or OD */ sec_acl_e_type_for_other_deleg, /* 19 -- FOREIGN_OTHER_DEL or FOD */ sec_acl_e_type_any_other_deleg /* 20 -- ANY_OTHER_DEL or AOD */ } sec_acl_entry_type_t;

Its semantics are that it indicates the type of an ACLE (the significance of which is manifested in access determination algorithms) -see ACLEs .

ACLE Permission Sets

A permission set; that is, the set of permissions associated to (or "carried by") an ACLE, is represented by the sec_acl_permset_t data type, which is defined as follows:

typedef unsigned32 sec_acl_permset_t;

Its semantics are that the individual bits (called permission bits) of a permission set indicate the access rights (up to 32 of them) granted or denied (masked) by an ACLE. The actual access semantics (that is, the "meaning" in the sense of access control) of these access rights is the responsibility of the ACL manager type associated with the ACL in which the ACLE occurs (see ACL Managers, Permissions, Access Determination Algorithms and ACL Managers ).

Extended ACLE Information

Extended ACLEs (that is, ACLEs of EXTENDED type) carry information that is represented by the sec_acl_extend_info_t data type, which is defined to be a pickle. In the terminology and notation of (IDL/NDR) Pickles , this pickle's type UUID (H.pkl_type) and its body bgcolor="#FFFFFF" datastream (which is an NDR-marshalled value of an IDL-defined data type) are to be interpreted on an application-specific basis; none are further specified in this revision of DCE. (Some such values may be registered and specified in future revisions of DCE.)

The rationale for extended ACLEs is as follows. Future revisions of DCE may add new ACLE types not present in previous revisions. Those new ACLE types are of course unknown to "old" ACL clients (such as, for example, ACL editor programs) conforming to the prevision revision. Therefore, new servers supporting the new ACLE types are expected to recognise (for example, via RPC interface version numbers) when an ACL operation (such as rdacl_lookup() or rdacl_replace()) comes from an old client, and to encode/decode the new ACLE types into/from the EXTENDED ACLE type (which the old client can handle at least sanely, if not intelligently). Thus, at this initial revision of DCE, the EXTENDED ACLE type is supported at specification level, though no servers actually need to encode/decode ACLEs into the EXTENDED type until such time as additional ACLEs are actually defined. ACL clients need to handle the EXTENDED type in order to migrate smoothly into the future, however.


ACLEs are represented by the sec_acl_entry_t data type, which is defined as follows:

typedef struct { sec_acl_permset_t permset; union sec_acl_entry_u switch (sec_acl_entry_type_t entry_type) tagged_union { case sec_acl_e_type_user_obj: case sec_acl_e_type_group_obj: case sec_acl_e_type_other_obj: case sec_acl_e_type_mask_obj: case sec_acl_e_type_unauthenticated: case sec_acl_e_type_any_other: case sec_acl_e_type_user_obj_deleg: case sec_acl_e_type_group_obj_deleg: case sec_acl_e_type_other_obj_deleg: case sec_acl_e_type_any_other_deleg: /*empty*/ /*... just the permset_t... */; case sec_acl_e_type_user: case sec_acl_e_type_group: case sec_acl_e_type_foreign_other: case sec_acl_e_type_user_deleg: case sec_acl_e_type_group_deleg: case sec_acl_e_type_for_other_deleg: sec_id_t local_id; case sec_acl_e_type_foreign_user: case sec_acl_e_type_foreign_group: case sec_acl_e_type_for_user_deleg: case sec_acl_e_type_for_group_deleg: sec_id_foreign_t foreign_id; case sec_acl_e_type_extended: [ptr] sec_acl_extend_info_t *extended_info; } entry_info; } sec_acl_entry_t;

Its semantics are that it indicates one entry of an ACL (see ACL Entries and their Types for generalities on the concept of ACLEs). Its fields are the following:


ACLs are represented by the sec_acl_t data type, which is defined as follows:

typedef struct { sec_id_t default_cell; uuid_t sec_acl_manager_type; unsigned32 count; [ptr, size_is(count)] sec_acl_entry_t *sec_acl_entries; } sec_acl_t;

Its semantics are that it indicates an access control list (see Access Control Lists (ACLs) for generalities on the concept of ACLs). Its fields are the following:

ACL Types

ACL types are represented by the sec_acl_type_t data type, which is defined as follows:

typedef enum { sec_acl_type_object, /* 0 */ sec_acl_type_default_object, /* 1 */ sec_acl_type_default_container /* 2 */ } sec_acl_type_t;

Its semantics are that it indicates the "type" of ACL associated to an object, as follows.

These ACL types are used for inheritance purposes, as specified in Object Types, ACL Types, and ACL Inheritance .

Common ACLs

In principle, a "legal" ACL (in the absolute sense of the generic ACL Facility mechanism itself, as opposed to the relative sense of the specific subset of well-formed ACLs supported by the policies of any specific ACL Manager) can contain any number of ACLEs of any types. But in the case of Common ACL Managers (see ACL Managers, Permissions, Access Determination Algorithms and ACL Managers ), any ACL managed by a Common ACL Manager is required to satisfy the following conditions. (In the context of Common ACL Managers, these conditions are known as common ACL formation rules, and such an ACL is known as a (well-formed) common ACL.)

The rules above that forbid "collisions" of ACLEs (that is, those that require ACLEs to be "distinct from one another"), are usually summarised by the paraphrase: "The ACLEs of a (well-formed) common ACL must all be of different specificity" (with the possible exceptions of USER_OBJ and GROUP_OBJ, depending on whether or not one considers these to be of the "same specificity" as USER/FOREIGN_USER and GROUP/FOREIGN_GROUP, respectively).

The above DCE formation rules should be compared with the following draft-POSIX formation rule (which is present in some drafts of the POSIX ACL standard): "Every ACL must have exactly one each of USER_OBJ, GROUP_OBJ, OTHER_OBJ; and if it has any USER, GROUP or application-defined entries, then it must have exactly one MASK_OBJ entry". This rule is not required by DCE. (This represents one of the ways that the ACL model supported by DCE generalises, in ways sanctioned by POSIX, that of the draft-POSIX models.)
Please note that the html version of this specification may contain formatting aberrations. The definitive version is available as an electronic publication on CD-ROM from The Open Group.

Contents Next section Index