Previous section.
DCE 1.1: Authentication and Security Services
Copyright © 1997 The Open Group
ACL Editor RPC Interface
This chapter specifies the RPC interface supporting ACL
Editors, namely the rdacl RPC interface (the corresponding
sec_acl API is specified in
Access Control List API
).
Recall that, by definition, "ACL Editors" are just RPC clients
that invoke the operations defined in this chapter to access and
manipulate (via the RPC server and its ACL managers) the ACLs on protected
objects, without actually accessing the protected objects themselves.
Required background for this chapter appears in
ACL Editors
,
Access Control Lists (ACLs)
and
ACL Managers
.
The rdacl RPC Interface
This section specifies (in IDL/NDR) the rdacl RPC interface.
All servers that support protected objects must export this RPC
interface in order for ACL Editors to be able to manage their ACLs.
They must also, of course, protect it (at a level consistent with
the policy of the server) in order to guarantee the security of the
server's ACLs and protected objects (see
Protected RPC
for generalities on Protected RPC, and see the required rights
specifications on the rdacl operations below).
This section begins with
some remarks about identifying protected objects and ACLs,
followed by definitions of some common data types, and
the rdacl interface interspersed with commentary explaining it.
Identifying Protected Objects and ACLs
The rdacl interface represents references to ACLs by a 4-tuple of
data items, namely:
-
An RPC binding handle, identifying the server that manages the protected
object whose ACL is being referenced.
-
A string, which "further identifies", on an application-specific basis
(that is, by a "server-supported namespace"-see
ACL Editors
),
the protected object within the server whose ACL is being referenced.
-
An ACL manager type UUID, identifying the ACL manager type of the
ACL being referenced (and thereby identifying the ACL manager within the
server that can interpret the ACL).
-
An ACL type, identifying the ACL type of the ACL being referenced (protection
ACL, default object creation ACL, default container creation ACL).
A consistent notation for these items is used throughout this section,
namely (in the order listed above):
-
-
handle_t rpc_handle;
sec_acl_component_name_t component_name;
uuid_t *manager_type;
sec_acl_type_t acl_type;
This identification scheme implies that servers supporting the
rdacl interface must uniquely identify all their ACLs by
means of such a 4-tuple. Within this constraint, however, the server's
management of its protected objects and ACLs is not further specified
here, so is application-specific.
- Note:
-
Typically, it is the case that the first 2 of the above items
(rpc_handle, component_name) together uniquely
identify the protected object itself, and the last 2 items
(manager_type, acl_type) together uniquely identify a
particular ACL associated with that protected object.
However, this is not a requirement. For example, it is
conceivable (though atypical) that a server (identified by
rpc_handle) could support more than one protected object
having the same stringname (component_name), provided those were
disambiguated (for ACL editing purposes) by being protected by ACL
managers of different type UUIDs (manager_type).
Again, it is entirely conceivable that a server could support protected
objects that are uniquely identified by stringname (component_name),
but having more than one ACL per object (these being disambiguated by their
manager_types).
This latter is the case of so-called "polymorphic types", and is
especially useful when the server supports a hierarchical namespace
whose internal nodes are not only "mere" directories but also
participate in some other role (such as a directory that participates
in some of the qualities of a leaf node).
Common Data Types and Constants for rdacl Interface
This section specifies (in IDL/NDR) common data types and constants used
by the rdacl interface (additional data types not defined in this
chapter are defined in preceding chapters and in the referenced Open Group DCE 1.1 RPC Specification).
sec_acl_component_name_t
The sec_acl_component_name_t data type is a string for
"further identifying" (in an application-specific manner) a protected
object (and hence its ACL)-see
Identifying Protected Objects and ACLs
.
Its character elements are to be drawn from the Portable Character Set
(see Appendix G, Portable Character Set, of the referenced Open Group DCE 1.1 RPC Specification).
-
-
typedef [string, ptr] unsigned char *sec_acl_component_name_t;
sec_acl_p_t
The sec_acl_p_t data type represents a pointer to an ACL.
-
-
typedef [ptr] sec_acl_t *sec_acl_p_t;
sec_acl_list_t
The sec_acl_list_t data type represents a list (array) of
(pointers to) ACLs.
-
-
typedef struct {
unsigned32 count;
[size_is(count)] sec_acl_p_t sec_acls[];
} sec_acl_list_t;
sec_acl_result_t
The sec_acl_result_t data type represents a
"performance-optimised" version of the sec_acl_list_t data type.
In the success case (status = error_status_ok),
sec_acl_result_t represents a (pointer to a) value of type
sec_acl_list_t; in the error case (status !=
error_status_ok) it is empty (thereby preventing unnecessary
marshalling/unmarshalling of data in the error case).
-
-
typedef union switch (error_status_t status) {
case error_status_ok:
[ptr] sec_acl_list_t acl_list;
default:
/*empty*/ /*empty*/;
} sec_acl_result_t;
sec_acl_twr_ref_t
The sac_acl_twr_ref_t data type represents a pointer to an
RPC protocol tower (twr_t, defined in
Appendix L, Protocol Tower Encoding, of the referenced Open Group DCE 1.1 RPC Specification).
-
-
typedef [ref] twr_t *sec_acl_twr_ref_t;
sec_acl_tower_set_t
The sec_acl_tower_set_t data type represents a pointer to a list of
(pointers to) RPC protocol towers.
-
-
typedef [ptr] struct {
unsigned32 count;
[size_is(count)] sec_acl_twr_ref_t towers[];
} *sec_acl_tower_set_t;
sec_acl_posix_semantics_t
The sec_acl_posix_semantics_t data type is a flag word
indicating the extent of POSIX semantics supported by an ACL manager.
-
-
typedef unsigned32 sec_acl_posix_semantics_t;
const sec_acl_posix_semantics_t sec_acl_posix_no_semantics
= 0x00000000;
const sec_acl_posix_semantics_t sec_acl_posix_mask_obj
= 0x00000001;
The following values are currently registered:
-
sec_acl_posix_no_semantics
ACL manager supports ACLs as described throughout DCE,
with the exception that the MASK_OBJ ACLE type is not supported
(that is, is not present on any ACL).
-
sec_acl_posix_mask_obj
ACL manager supports ACLs as described throughout DCE
(including the MASK_OBJ ACLE type).
- Note:
- Arguably, DCE "should" support a sec_acl_semantics_t
flag word data type, encompassing "all" kinds of semantics, not just
those related to POSIX. Such support is for future study. For the time
being, DCE restricts itself to "POSIX-like" semantics, and the
intention is that the bits of the sec_acl_posix_semantics_t
indicate various "levels" or "flavours" of POSIX-like semantics.
Status Codes
The following status codes (transmitted as values of the type
error_status_t) are specified for the rdacl interface. Only
their values are specified here-their use is specified in context
elsewhere in this specification.
const unsigned32 sec_acl_not_implemented = 0x17122016;
const unsigned32 sec_acl_cant_allocate_memory = 0x17122017;
const unsigned32 sec_acl_invalid_site_name = 0x17122018;
const unsigned32 sec_acl_unknown_manager_type = 0x17122019;
const unsigned32 sec_acl_object_not_found = 0x1712201a;
const unsigned32 sec_acl_no_acl_found = 0x1712201b;
const unsigned32 sec_acl_invalid_entry_name = 0x1712201c;
const unsigned32 sec_acl_expected_user_obj = 0x1712201d;
const unsigned32 sec_acl_expected_group_obj = 0x1712201e;
const unsigned32 sec_acl_invalid_entry_type = 0x1712201f;
const unsigned32 sec_acl_invalid_acl_type = 0x17122020;
const unsigned32 sec_acl_bad_key = 0x17122021;
const unsigned32 sec_acl_invalid_manager_type = 0x17122022;
const unsigned32 sec_acl_read_only = 0x17122023;
const unsigned32 sec_acl_site_read_only = 0x17122024;
const unsigned32 sec_acl_invalid_permission = 0x17122025;
const unsigned32 sec_acl_bad_acl_syntax = 0x17122026;
const unsigned32 sec_acl_no_owner = 0x17122027;
const unsigned32 sec_acl_invalid_entry_class = 0x17122028;
const unsigned32 sec_acl_unable_to_authenticate = 0x17122029;
const unsigned32 sec_acl_name_resolution_failed = 0x1712202a;
const unsigned32 sec_acl_rpc_error = 0x1712202b;
const unsigned32 sec_acl_bind_error = 0x1712202c;
const unsigned32 sec_acl_invalid_acl_handle = 0x1712202d;
const unsigned32 sec_acl_no_update_sites = 0x1712202e;
const unsigned32 sec_acl_missing_required_entry = 0x17122030;
const unsigned32 sec_acl_duplicate_entry = 0x17122031;
const unsigned32 sec_acl_bad_parameter = 0x17122032;
const unsigned32 sec_acl_not_authorized = 0x17122033;
const unsigned32 sec_acl_server_bad_state = 0x17122034;
const unsigned32 sec_acl_invalid_dfs_acl = 0x17122035;
const unsigned32 sec_acl_bad_permset = 0x17122037;
Interface UUID and Version Number for rdacl Interface
The interface UUID and version number for the rdacl interface
are given by the following:
-
-
[uuid(47b33331-8000-0000-0d00-01dc6c000000), version(0.0)]
interface rdacl
{ /* begin running listing of rdacl interface */
Implementation Variability Regarding Required Rights
The RPC (rdacl) operations specified in this chapter are intended
to be implemented by various kinds of servers, whose detailed specification
is in general beyond the scope of this specification, and all of
whose security requirements cannot therefore be anticipated by DCE.
In particular, the authorisation policies ("required rights")
to the server's ACLs are the responsibility of the server itself (or
more precisely, of its ACL manager(s)), and are in general beyond the
scope of this document. As such, the specifications of required rights in
this chapter are to be interpreted as suggestions only, whose exact
interpretation must be specified by the implementing servers. To
emphasise this, the permissions mentioned in the required rights of this
chapter are given hypothetical "names", explicitly denoted with
quotation marks (indicating that their exact interpretation is to
be specified by the specific server in question). Typical
interpretations of these hypothetical permissions are given as suggestions.
For an explicit example of a concrete interpretation, namely in the
specific case of the RS server (whose specification is within the
scope of this document), see
RS Protected Objects and their ACL Manager Types
.
rdacl_lookup()
The
rdacl_lookup()
operation retrieves ("reads") all ACLs
specified by an <rpc_handle, component_name,
manager_type, acl_type> 4-tuple, creating a copy locally on
the client.
-
-
void
rdacl_lookup (
[in] handle_t rpc_handle,
[in] sec_acl_component_name_t component_name,
[in] uuid_t *manager_type,
[in] sec_acl_type_t acl_type,
[out] sec_acl_result_t *acl_result );
The rpc_handle parameter identifies the server that manages the
protected object.
The component_name parameter further identifies the protected object
within the server.
The manager_type parameter identifies an ACL manager type UUID.
The acl_type parameter identifies an ACL type.
The acl_result parameter returns the result of the operation.
Required rights (suggested):
This operation succeeds only if the calling
client has "rdacl-lookup" permission (to the specified protected object,
according to the specified ACL manager's policy-see
Implementation Variability Regarding Required Rights
).
Typically, servers will grant this
permission to clients which have Read-ACL permission to the protected
object in question (which, in turn, is typically interpreted as
any access-see
ACL Managers, Permissions, Access Determination Algorithms
).
rdacl_replace()
The
rdacl_replace()
operation applies ("writes") all ACLs
specified by an <rpc_handle, component_name,
manager_type, acl_type> 4-tuple.
This operation is atomic, in the sense that it manipulates a whole
ACL (not its individual ACLEs, and it cannot be "interrupted" by
another invocation of
rdacl_replace())
-thus, the specified new ACL entirely replaces the old (existing)
ACL on the protected object.
-
-
void
rdacl_replace (
[in] handle_t rpc_handle,
[in] sec_acl_component_name_t component_name,
[in] uuid_t *manager_type,
[in] sec_acl_type_t acl_type,
[in] sec_acl_list_t *acl_list,
[out] error_status_t *status );
The rpc_handle parameter identifies the server that manages the
protected object.
The component_name parameter further identifies the protected
object within the server.
The manager_type parameter identifies an ACL manager type UUID.
The acl_type parameter identifies an ACL type.
The acl_list parameter specifies the new ACLs to replace the old ACLs.
The status parameter returns the status of the operation.
Required rights (suggested):
This operation succeeds only if the calling
client has "rdacl-replace" permission (to the specified protected object,
according to the specified ACL manager's policy-see
Implementation Variability Regarding Required Rights
).
Typically, servers will grant this permission to
clients which have Control (Write-ACL) permission to the protected
object in question (see
ACL Managers, Permissions, Access Determination Algorithms
).
rdacl_get_access()
The
rdacl_get_access()
operation determines the calling client's
access rights to the protected object specified by an
<rpc_handle, component_name, manager_type> 3-tuple.
-
-
void
rdacl_get_access (
[in] handle_t rpc_handle,
[in] sec_acl_component_name_t component_name,
[in] uuid_t *manager_type,
[out] sec_acl_permset_t *access_rights,
[out] error_status_t *status );
The rpc_handle parameter identifies the server that manages the
protected object.
The component_name parameter further identifies the protected object
within the server.
The manager_type parameter identifies an ACL manager type UUID.
The access_rights parameter returns the calling client's access
rights to the specified protected object.
This is the client's "maximum" access rights; that is, the "union"
(bitwise OR) of all the
permission bits granted to the client, according to the ACLs on the
protected object of ACL type sec_acl_type_object.
The status parameter returns the status of the operation.
Required rights (suggested):
This operation succeeds only if the calling
client has "rdacl-get-access" permission (to the specified protected object,
according to the specified ACL manager's policy-see
Implementation Variability Regarding Required Rights
).
Typically, servers will grant this
permission to clients which have Read-ACL permission to the protected
object in question (which, in turn, is typically interpreted as
any access-see
ACL Managers, Permissions, Access Determination Algorithms
).
rdacl_test_access()
The
rdacl_test_access()
operation determines ("tests") whether or not the calling client has the
specified access rights to a protected object.
-
-
boolean32
rdacl_test_access (
[in] handle_t rpc_handle,
[in] sec_acl_component_name_t component_name,
[in] uuid_t *manager_type,
[in] sec_acl_permset_t access_rights,
[out] error_status_t *status );
The rpc_handle parameter identifies the server that manages the
protected object.
The component_name parameter further identifies the protected object
within the server.
The manager_type parameter identifies an ACL manager type UUID of
the protected object.
The access_rights parameter identifies the specific access rights
(according to the ACLs on the protected object of ACL type
sec_acl_type_object) to be tested.
The status parameter returns the status of the operation.
The boolean32 return value of this operation, which is valid only
when status returns error_status_ok, returns 0
("false") if the calling client is denied access, non-0 ("true") if
the client is granted access.
Required rights (suggested):
This operation succeeds only if the calling
client has "rdacl-test-access" permission (to the specified
protected object,
according to the specified ACL manager's policy-see
Implementation Variability Regarding Required Rights
).
Typically, servers will grant this
permission to all clients (that is, no permissions are required).
rdacl_place_holder_1()
The
rdacl_place_holder_1()
operation is merely an IDL place-holder; it is a "no-op" (that is, the
specification of its semantics is empty). (The presence of this operation is
anachronistic, but necessary.)
-
-
boolean32
rdacl_place_holder_1 (
[in] handle_t rpc_handle,
[in] sec_acl_component_name_t _1_,
[in] uuid_t *_2_,
[in, ptr] sec_id_pac_t *_3_,
[in] sec_acl_permset_t _4_,
[out] error_status_t *status );
The rpc_handle parameter identifies the server that manages the
protected object.
The _1_ parameter has unspecified semantics.
The _2_ parameter has unspecified semantics.
The _3_ parameter has unspecified semantics.
The _4_ parameter has unspecified semantics.
The status parameter returns the status of the operation.
It always returns sec_acl_not_implemented.
The boolean32 return value of this operation
always returns 0 ("false").
Required rights (suggested):
None.
rdacl_get_manager_types()
The
rdacl_get_manager_types()
operation retrieves the types of ACL managers protecting a protected object.
-
-
void
rdacl_get_manager_types (
[in] handle_t rpc_handle,
[in] sec_acl_component_name_t component_name,
[in] sec_acl_type_t acl_type,
[in] unsigned32 count_max,
[out] unsigned32 *count,
[out] unsigned32 *num_manager_types,
[out, size_is(count_max), length_is(*count)]
uuid_t manager_types[],
[out] error_status_t *status );
The rpc_handle parameter identifies the server that manages the
protected object.
The component_name parameter further identifies the protected object
within the server.
The acl_type parameter identifies an ACL type.
The count_max parameter identifies the maximum number of ACL manager
type UUIDs to be returned (in manager_types).
The count parameter identifies the actual number of ACL manager type
UUIDs returned (in manager_types).
The num_manager_types parameter identifies the total number of ACL
manager types, of ACL type acl_type, at the heads of chains
(see
rdacl_get_printstring(),
rdacl_get_printstring()
),
protecting the protected object-thus, an invocation of
this operation is "completely successful" only if
count = num_manager_types.
The manager_types parameter is an array (of size count) of
distinct UUIDs identifying different ACL manager types protecting the
protected object (in the case of a chain of ACL managers, each
supporting <= 32 permission bits, only the first ACL manager in the
chain is returned in this way, and the rest are returned by calls to
rdacl_get_printstring()
-see
rdacl_get_printstring()
).
The status parameter returns the status of the operation.
Required rights (suggested):
This operation succeeds only if the calling client
has "rdacl-get-manager-types" permission (to the specified protected
object, according to the specified server's policy (which may, in turn,
depend on the policies of the protected object's ACL managers)-see
Implementation Variability Regarding Required Rights
).
Typically, servers will grant this
permission to all clients (that is, no permissions are required).
rdacl_get_printstring()
The
rdacl_get_printstring()
operation retrieves printstring
representations for the permission bits that an ACL manager supports.
-
-
void
rdacl_get_printstring (
[in] handle_t rpc_handle,
[in] uuid_t *manager_type,
[in] unsigned32 count_max,
[out] uuid_t *manager_type_next,
[out] sec_acl_printstring_t *manager_info,
[out] boolean32 *tokenize,
[out] unsigned32 *num_printstrings,
[out] unsigned32 *count,
[out, size_is(count_max), length_is(*count)]
sec_acl_printstring_t printstrings[],
[out] error_status_t *status );
The rpc_handle parameter identifies the server that manages the
ACL manager.
The manager_type parameter identifies an ACL manager type UUID.
The count_max parameter identifies the maximum number of
printstrings to be returned (in printstrings).
The manager_type_next parameter, if not equal to uuid_nil,
identifies the next ACL manager type in a linked list or "chain"
of ACL manager types,
which can be successively followed until the chain is exhausted
(for example, such a chain can be used to support > 32 permission bits).
The value uuid_nil indicates the end of this chain.
The manager_info parameter provides a name and help information
for the manager_type
ACL manager as a whole (as opposed to any of its specific
permission bits-those are described in the printstrings
parameter), as well as a complete list of all its supported permission bits
(represented as the union (bitwise OR) of all those supported bits).
Concerning this bitwise OR, it is suggested that, by convention,
"simple" or "primitive" permission bits (for example, permissions
having semantics not
interpretable in terms of other permissions) appear in low-order bit
positions (and in particular, that the 7 common permission bits, if
present, occupy their usual places in the low-order 7 bit positions,
0x0000007f-see
Common Permissions
),
and that "complex" or "combination" permission bits (for example,
permissions having semantics interpretable in terms of other
permissions) appear near the high-order end. Thus, for example, for an
ACL manager supporting the first 6 of the 7 common permission bits
(rwxcid but not t) plus 2 combination
bits, one with value 0x00000080 and having the semantics "Read and
Write", and the other with value 0x00000100 and having the semantics
"Read or Write", this bitwise OR would be equal to 0x000001bf.
- Note:
- This example, using "combined rights", is contrived
to illustrate the problem of tokenisation (below)-it is not
necessarily a realistic example. Combining rights in this manner is not
necessarily to be encouraged, and the merits/demerits of doing so are
not debated here.)
The tokenize parameter identifies potential ambiguity in the
concatenation of permission printstrings (that is, in the
printstring fields of the elements of the printstrings[]
array)-when tokenize is 0 ("false"), the permission
printstrings may be concatenated into a single string without
ambiguity; when non-0 ("true"), this property does
not hold, and the permission printstrings must be "tokenised"
(that is,
separated by disambiguating characters; for example, by non-alphanumeric
characters, such as whitespace) to avoid ambiguity when concatenated.
The consumer of the tokenize parameter is typically a
user interface program (for example, an ACL editor) which wants to display
printstrings to users, and must do so unambiguously.
Thus in the example above, if the two combination permissions
were represented by, say, the printstrings raw (for "Read and
Write") and row (for "Read or Write"), then tokenize
would be non-0 (because these printstrings have characters in common
with one another, as well as with the common printstrings r
("Read") and w ("Write"), and this could potentially be
confusing to human users). In this example, a user interface
program could display the 8 supported permissions to humans in a manner
such as: r*w*x*c*i*d*raw*row,
where "*" denotes the space character (for visual clarity).
Alternatively (and probably preferably), tokenisation could have been
avoided in this example by choosing different printstrings for the
combination permissions, such as a and o instead of
raw and row, in which case a user interface program could
display the supported permissions as rwxcidao. (Note that the
order of display of permission bits need not be correlated to the order
of their values-that's an implementation decision of the
user interface program itself, though the reverse-value order indicated
here is suggested, for consistency with the well-known 7 common
permissions, rwxcidt.)
The num_printstrings parameter identifies the total number
(<= 32) of permission bits and
printstrings "supported" (in the sense of
rdacl_get_printstring(),
as indicated in the following sentence) by the ACL manager (thus,
an invocation of this operation is "completely successful" only if
count = num_printstrings).
In the example above, the value of num_printstrings is 9,
even though only 8 permission bits are "actually supported" by the
manager_type ACL manager (the t bit is not supported, but
its position is reserved by convention, so must be skipped).
The count parameter identifies the actual number of printstrings
returned (in the printstrings array).
In the example above, the value of count is 9.
The printstrings parameter is an array (of size count) of
printstrings returning information about the permission bits
(see manager_info above) supported by the ACL manager.
(See
Printstrings and Helpstrings
.)
The correspondence between supported permission bits and information
about those bits is realised "as if" it were given by an array of
permission bit / printstring pairs
(unsupported permission bits corresponding to NULL printstrings). That
is, if permission bit
2k (0 <= k <= 31) is supported
(this bit is set in the perm field of
manager_info-see
Printstrings and Helpstrings
),
then printstring[k] contains the information about this
permission bit.
Unsupported permissions correspond to NULL printstrings.
Thus in the example above, printstring[6] is
NULL because it corresponds to the unsupported permission bit t.
The status parameter returns the status of the operation.
Required rights (suggested):
This operation succeeds only if the calling client
has "rdacl-get-printstring" permission (to the specified ACL manager,
according to the specified ACL manager's policy-see
Implementation Variability Regarding Required Rights
).
Typically, servers will grant this permission to all clients
(that is, no permissions are required).
rdacl_get_referral()
The
rdacl_get_referral()
operation supports a server replication strategy wherein ACL "updates"
(.Fn rdacl_replace )
may not be supported
at all "sites" (that is, by all server instances or replicas).
This operation, which refers clients to sites where ACLs can
be updated, is to be invoked by a client after an update operation
targeted to an ACL site yields a sec_acl_site_read_only status
error != error_status_ok. (Non-replicated servers never return a
sec_acl_site_read_only status value, so they can provide a trivial
implementation of this operation; for example, by returning
sec_acl_not_implemented as the status parameter.)
-
-
void
rdacl_get_referral (
[in] handle_t rpc_handle,
[in] sec_acl_component_name_t component_name,
[in] uuid_t *manager_type,
[in] sec_acl_type_t acl_type,
[out] sec_acl_tower_set_t *tower_set,
[out] error_status_t *status );
The rpc_handle parameter identifies the server that manages the
ACLs in question.
The component_name parameter further identifies a protected object
within the server.
The manager_type parameter identifies an ACLE manager type UUID.
The acl_type parameter identifies an ACL type.
The tower_set parameter identifies the actual update referral
information itself (represented as RPC towers, to which the client can
rebind).
The status parameter returns the status of the operation.
Required rights (suggested):
This operation succeeds only if the calling
client has "rdacl-get-referral" permission (to the specified server,
according to the server's policy-see
Implementation Variability Regarding Required Rights
).
Typically, servers will grant this
permission to all clients (that is, no permissions are required).
rdacl_get_mgr_types_semantics()
The
rdacl_get_mgr_types_semantics()
operation determines the types of ACL managers protecting a protected object,
and the extent of their conformance to POSIX semantics.
-
-
void
rdacl_get_mgr_types_semantics (
[in] handle_t rpc_handle,
[in] sec_acl_component_name_t component_name,
[in] sec_acl_type_t acl_type,
[in] unsigned32 count_max,
[out] unsigned32 *count,
[out] unsigned32 *num_manager_types,
[out, size_is(count_max), length_is(*count)]
uuid_t manager_types[],
[out, size_is(count_max), length_is(*count)]
sec_acl_posix_semantics_t posix_semantics[],
[out] error_status_t *status );
} /* end running listing of rdacl interface */
The description of
rdacl_get_mgr_types_semantics()
is identical to that of
rdacl_get_manager_types(),
except that it returns the additional posix_semantics array parameter.
The posix_semantics parameter is an array
of flag words indicating the semantics that the
corresponding ACL manager in the manager_types array supports.
Required rights (suggested):
This operation succeeds only if the calling client
has "rdacl-get-mgr-types-semantics" permission (to the specified protected
object, according to the specified server's policy-which may, in turn,
depend on the policies of the protected object's ACL managers-see
Implementation Variability Regarding Required Rights
).
Typically, servers will grant this
permission to all clients (that is, no permissions are required).
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.