Description

ACLs consist of ACL entries. ACL entries are visible only as members of ACLs. There is no object that represents ACL entries, only the acl object representing an entire ACL. Most of the acl operations deal directly with the ACL. See the Data Structures topic for a description of the syntax of ACLs and ACL entries. An ACL has one attribute, called cell, that represents the default cell of the ACL.

In most cases, the name of an object also specifies the name of the associated ACL to manipulate. However, some objects have more than one ACL, and some names can refer to more than one object. These ambiguities are resolved by using various options on the command line.

An object can have more than one ACL. For example, container objects - such as CDS directories and directories in the registry - have three ACLs: one ACL controls access to the container object itself, a second ACL specifies the default ACL on new objects added to the container (the initial object ACL), and a third ACL specifies the default ACL on new containers added to the container (the initial container ACL). By default the acl commands operate on the ACL of the container object. Use the -ic option to operate on the initial container ACL. Use the -io option to operate on the initial object ACL. Simple objects (those that are not container objects) do not have initial container or initial object ACLs.

Some servers that have ACLs also store their network location information in a server entry in (CDS). The server entry has the same name as the server itself and may also have an attached ACL. Use the -entry option to operate on the server entry ACL in CDS rather than the server's ACL.

All dced objects have ACLs. When the dced on the local machine is in partial service mode, you must use the -local option to access dced object ACLs. To access dced object ACLs, specify only the residual portion of the object name to the acl command. For example, use hostdata, not /.:/hosts/gumby/config/hostdata.

Some DCE objects have more than one purpose. For instance, a registry object can represent a principal and it can also act as a directory (a container). An example is a principal name that identifies another cell (for instance, /.../comp.com) with which you want to establish authenticated operation. In this case the cell maintains a principal name /.:/comp.com. The registry object for this principal name is:

/.:/sec/principal/comp.com

Assume the cell also has a hierarchical (subordinate) cell named /.../comp.com/test_cell. The cell maintains another principal name /.:/comp.com/test_cell. The registry object for this principal name is:

/.:/sec/principal/comp.com/test_cell

Consequently, the registry object /.:/sec/principal/friendly.company.com also acts as a directory because it contains the hierarchical cell name /.:/sec/principal/friendly.company.com/test_cell. The ACL manager that operates on registry objects differs from the ACL manager that operates on registry directories. For instance, the latter ACL manager has an insert (i) permission bit that controls who can add new objects to the directory. Consequently, most acl commands provide a -type option that lets you specify the appropriate ACL manager when operating on registry objects that are also directories. You can list the ACL managers that are available for registry objects using the acl show -managers command.