Authorization Overview

4-2

An ACL contains a list of entries that specify the principals who can access an object and the operations those principals can perform. The principals can be named specifically or be members of a group that is identified in the ACL entry. The ACL is associated with the object it protects. The operations a principal can perform are specified by permissions.

Although UNIX permissions, called "permission bits," can be set only for file system objects (files and directories), in DCE many objects can have ACLs and be assigned permissions. DCE ACLs control access to objects managed by DCE components, like the Distributed File Service, the Security Service, and the Directory Service. ACLs for the Registry Service (the Security component that controls accounts) can, for example, authorize certain principals to change all of the information associated with an account, authorize other principals to change only a subset of the information associated with accounts, and restrict other principals from changing any of the information associated with accounts.

In addition to the standard DCE components, ACLs can control any object for which an ACL Manager (described later in this chapter) has been implemented. ACLs can be associated with user-written applications to protect access to the use of the application itself, the files in the application, and even fields in those files.

In UNIX systems, because only file system objects are protected by permission bits, a standard set of permissions (read, write, and execute) can be used. In DCE, however, the names and meanings of the permissions themselves can be defined individually for each type of DCE object. For example, the file system uses the familiar read, write, and execute permissions, but the Registry Service uses a more extensive set of permissions specifically tailored to its authorization requirements.

DeE User's Guide and Reference

4.1.1 ACL Interpretation

Part of the information associated with an account is the principal name and the group (or groups) associated with the principal name in the account.

The UUIDs that represent the principal's name and group names are known as the principal's privilege attributes. If the principal's privilege attributes have been supplied by the Authentication Service, they are said to be

"certified privilege attributes." Principals without certified privilege attributes are allowed only unauthenticated access to objects.

Unauthenticated access, if it is allowed at all, is generally more restrictive than authenticated access.

4.1.1.1 Privilege Attributes Inherited by Processes

Processes created or spawned by a principal inherit the principal's privilege attributes. For example, if you log in, are authenticated, and start an application, the application you start inherits your authenticated privilege attributes and runs as though it were you. The application's permissions for any given object are the same as your permissions. Processes spawned by the application carry your identity and pass it down to processes they start.

Note: Changing the setuid permission bit changes only the local identity under which an executable file· runs, not the network identity.

Some servers are written to run as separate authenticated principals. For these servers, your system administrator creates an account in the registry database. After you start these servers, the server process performs the equivalent of a user login, receives its privilege attributes, and runs under its own identity, not yours.

4.1.1.2 Granting Access

When a principal requests access to a DCE object associated with an ACL, the object's ACL Manager compares the principal's privilege attributes with the entries in the object's ACL. It does this simply by reading through the list of ACL entries. The Manager grants the access permissions in the ACL entries that match the principal's privilege attributes. To do this, the ACL Manager uses the access check algorithm, described in Section 4.12.

If the permissions allow the requested mode of access, the principal gains access; if not, access is denied.

4.1.2 ACL Managers

One ACL Manager may support multiple Manager types, each Manager type implementing a different permission set. For example, access to the registry is controlled by five ACL Manager types, each controlling ACLs for a different type of object in the registry database. The ad_edit command that adds and modifies ACL entries has a subcommand to list the permissions specific to the ACL associated with the named object.

All of the elements of ACLs described in this chapter are available to ACL Managers; however, each Manager may implement all or only a subset of the elements. For information on how ACLs are used by specific DCE components, consult that component's section of the OSF DeE Administration Guide.

4.1.3 Extended Protection

4-4

In UNIX, permission bits are set for each file system object's owner and group. All other principals are grouped into the general category of

"other." The permission bits set for "other" apply to all principals except the object's owner and the members of the object's group. ACLs, on the other hand, extend this somewhat restrictive UNIX protection mechanism and give finely tuned control over access to objects.

DeE User's Guide and Reference

In addition to entries similar to UNIX owner, group, and other, DCE permissions can be set for

• Specific individual principals in the local cell and in foreign cells

• Specific individual groups in the local cell and in foreign cells

• All other principals in a specific foreign cell for whom individual permissions have not been set

• All principals in any cell who have been authenticated by the DCE Authentication Service

ACLs also provide a masking capability and a method for integrating protections from DCE versions that are different from the current version.