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

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:

• permset

  The permission set associated with this ACLE.

• entry_type

  The ACLE type of this ACLE.

• entry_info

  Additional information associated with this ACLE. The additional information consists of the following, according to this ACLE's type:

  • USER_OBJ, GROUP_OBJ, OTHER_OBJ, MASK_OBJ, UNAUTHENTICATED, ANY_OTHER, USER_OBJ_DEL, GROUP_OBJ_DEL, OTHER_OBJ_DEL, ANY_OTHER_DEL

    No additional information (just the permset).

  • USER, GROUP, FOREIGN_OTHER, USER_DEL, GROUP_DEL, FOREIGN_OTHER_DEL

    A tag (local_id), indicating that this ACLE refers to a particular user or group in the "default cell (of the ACL in which this ACLE occurs)" (see below), or to a particular "non-default cell".

  • FOREIGN_USER, FOREIGN_GROUP, FOREIGN_USER_DEL, FOREIGN_GROUP_DEL

    A tag (foreign_id), indicating that this ACLE refers to a particular user or group in a (specified) "non-default cell (of the ACL in which this ACLE occurs)".

  • EXTENDED

    Extended information (extended_info) associated with this ACLE. See Extended ACLE Information for details.

ACLs

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:

• default_cell

  The "default cell" associated with this ACL (see ACLEs and the Common Access Determination Algorithm in ACL Managers ).

• sec_acl_manager_type

  The ACL manager type that can interpret this ACL (see ACL Managers ).

• count

  The number of ACLEs in this ACL.

• sec_acl_entries

  The actual ACLEs in this ACL.

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.

• sec_acl_type_object

  Indicates a protection ACL attached to an object (either simple object or container object).

• sec_acl_type_default_object

  Indicates a default object creation ACL attached to a container object.

• sec_acl_type_default_container

  Indicates a default container creation ACL attached to a container object.

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.)

• It contains only ACLEs of types specified by sec_acl_entry_type_t (see ACLE Types ).

• It contains no EXTENDED ACLEs (see Extended ACLE Information for an explanation of EXTENDED ACLEs).

• Its total number of ACLEs is in the range [0, 2³²-1].

• It contains at most one USER_OBJ ACLE.

• All its USER ACLEs (if any) refer to principals distinct from one another (though not necessarily distinct from the principal referred to by the USER_OBJ ACLE, if present).

• It contains at most one GROUP_OBJ ACLE.

• All its GROUP ACLEs (if any) refer to groups distinct from one another (though not necessarily distinct from the group referred to by the GROUP_OBJ ACLE, if present).

• It contains at most one OTHER_OBJ ACLE.

• All its FOREIGN_USER ACLEs (if any) refer to principals distinct from one another, and from the principals referred to by the USER ACLEs if present (though not necessarily distinct from the principal referred to by the USER_OBJ ACLE, if present).

• All its FOREIGN_GROUP ACLEs (if any) refer to groups distinct from one another, and from the groups referred to by the GROUP ACLEs if present (though not necessarily distinct from the group referred to by the GROUP_OBJ ACLE, if present).

• All its FOREIGN_OTHER ACLEs (if any) refer to cells distinct from one another, and from the cell referred to by the OTHER_OBJ ACLE if present.

• It contains at most one ANY_OTHER ACLE.

• It contains at most one MASK_OBJ ACLE.

• It contains at most one UNAUTHENTICATED ACLE.

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).

Note:

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.)