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