PreviousNext

ACL Entries

An ACL entry has the following syntax:

type[:key]:permissions

where:

type
Identifies the role of the ACL entry.

key
Identifies the specific principal or group to whom the entry applies. For an entry type of extended, key contains the ACL data.

permissions
Specifies the ACL permissions.

A description of each syntax component follows.

type Component
The type tag identifies the role of the ACL entry. Valid types are the following:

· user_obj - Permissions for the objects real or effective user.

· group_obj - Permissions for the objects real or effective group.

· other_obj - Permissions for others in the local cell who are not otherwise named by a more specific entry type.

· user - Permissions for a specific principal user in the ACLs cell. This type of ACL entry must include a key that identifies the specific principal.

· group - Permissions for a specific group in the ACLs cell. This type of ACL entry must include a key that identifies the specific group.

· foreign_user - Permissions for a specific, authenticated user in a foreign cell. This type of ACL entry must include a key that identifies the specific principal and the principals cell.

· foreign_group - Permissions for a specific, authenticated group in a foreign cell. This type of ACL entry must include a key that identifies the specific group and the groups cell.

· foreign_other - Permissions for all authenticated principals in a specific foreign cell, unless those principals are specifically named in an ACL entry of type foreign_user or members in a group named in an entry of type foreign_group. This type of ACL entry must include a key that identifies the specific foreign cell.

· any_other - Permissions for all authenticated principals unless those principals match a more specific entry in the ACL.

· mask_obj - Permissions for the object mask that is applied to all entry types except user_obj, other_obj, and unauthenticated.

· unauthenticated - Maximum permissions applied when the accessor does not pass authentication procedures. This entry is used for principals that have failed authentication due to bad keys, principals that are entirely outside of any authentication cell, and principals that choose not to use authenticated access. Permissions granted to an unauthenticated principal are masked with this entry, if it exists. If this entry does not exist, access to unauthenticated principals is always denied.

· extended - A special entry that allows client applications running at earlier DCE versions to copy ACLs to and from ACL managers running at the current DCE version without losing any data. The extended entry allows the application running at the lower version to obtain a printable form of the ACL. The extended ACL entry has the following form:

extended:uuid.ndr.ndr.ndr.ndr.number_of_byte.data

where:

uuid
Identifies the type of extended ACL entry. (This UUID can identify one of the ACL entry types described here or an as-yet-undefined ACL entry type.) Up to three Network Data Representation (NDR) format labels (in hexadecimal format and separated by periods) that identify the encoding of data.

number_of_bytes
A decimal number that specifies the total number of bytes in data.

data
The ACL data in hexadecimal form. (Each byte of ACL data is two hexadecimal digits.) The ACL data includes all of the ACL entry specifications except the permissions (described later) that are entered separately. The data is not interpreted; it is assumed that the ACL manager to which the data is being passed can understand that data.

key Component
The key identifier (principal or group name) specifies the principal or group to which the ACL entry applies. For entries of entry type extended, key is the data passed from one ACL manager to another. A key is required for the following types of ACL entries:

· user - Requires a principal name only.

· group - Requires a group name only.

· foreign_user - Requires a fully qualified cell name in addition to the principal name.

· foreign_group - Requires a fully qualified cell name in addition to the group name.

· foreign_other - Requires a fully qualified cell name.

permissions Component
The permissions argument specifies the set of permissions that defines the access rights conferred by the entry. Since each ACL manager defines the permission tokens and meanings appropriate for the objects it controls, the actual tokens and their meanings vary. For example, the Distributed File Service, the Directory Service, and the Security Registry Service each implement a separate ACL manager, and each can use a different set of tokens and permissions. This means that file system objects, objects in the namespace, and registry objects could each use different permissions. Use the p[ermissions] subcommand to display the currently available tokens and their meanings. See the documentation for the DCE component you are using to obtain a more detailed description of its specific permissions.

Examples

1. The following example uses the interactive interface to set permissions for the unauthenticated and mask_obj entry type:

sec_acl_edit> m mask_obj:rwx
sec_acl_edit> m unauthenticated:r

2. The following example uses the interactive interface to set permissions for the effective user, group, and others in the ACLs cell:

sec_acl_edit> m user_obj:crwx
sec_acl_edit> m group_obj:rwx
sec_acl_edit> m other_obj:rwx

3. The following example uses the command-line interface to invoke acl_edit and assign permissions for the file progress_chart to the authenticated user mike in the local cell:

acl_edit /.../dresden.com/fs/walden/progress_chart -m user:mike:crwx

Note that because this entry is filtered through the object mask (mask_obj), which specifies only rwx permissions, the actual permissions will be rwx, not crwx. The l(ist) subcommand shows those permissions as follows:

user:mike:crwx #effective -rwx---

4. The following example uses the interactive interface to set permissions for the authenticated foreign user named burati in the cell named /.../usc-cs.uscal.edu:

sec_acl_edit> m foreign_user:/.../usc-cs.uscal.edu/sailing/staff/burati:rwx

5. The following example uses the non-interactive command-line interface to invoke acl_edit and set the Initial Container Creation permissions for the directory that is named walden:

acl_edit /.../dresden.com/fs/walden -ic -m /user:walden:crwxid

Related Information
Commands: acl(8dce)