How ACLs Work to Control Access to SPD Server Resources

Each server user has a unique user ID and can be a member of one or more ACL groups. The user must specify his or her user name in the SPD Server LIBNAME statement in order to connect to the server. The group name is optional and, if not specified, will default to the first group that is defined for the user in the password database.

When a user creates a resource, their user ID and active group membership are saved in the resource metadata, and are later used to authorize access to the resource. Initially, only the owner of the resource is authorized to access the resource, with two exceptions:

When opening a resource, the server compares the user ID from the SPD Server LIBNAME statement against the user ID that is stored with the resource. If the user IDs are the same, the requesting user is granted access to the resource. If they are not the same, the requesting user can access the resource only if the owner has created an ACL for the resource, and the ACL grants him or her access.

A resource ACL can define access permissions to specific users and groups. It can also grant universal access to all members of the owner’s group and universal access to all users. The server uses precedence levels to evaluate eligibility for access. The precedence check stops when a match is found for the requesting user’s credentials, or the precedence check completes without finding a match, which indicates the user was not intended to have access.

The precedence of the permission checks for resources in a domain can differ depending on whether administrators set the LIBACLINHERIT=YES option with the OWNER= specification in the domain definition.

When a user attempts to access resources in a domain that does not have LIBACLINHERIT=YES, the following ACL precedence of permissions checks are made on the resource:

When a user attempts to access resources in a domain that has LIBACLINHERIT=YES, the following ACL precedence of permissions checks are made on the resource:

In both scenarios, a specific user or group permission assignment in the ACL overrides any universal permissions that are defined.

Consider a user who is trying to open a resource that he or she does not own, and the owner created an ACL on the resource. The server will use the resource ACL and follow the precedence checks to determine whether the user has access. The user precedence check is TRUE if the requesting user ID matches a user record in the ACL. The user access is allowed or denied based on the permissions defined in that user record. If there is no record that matches the requesting user ID in the resource ACL, then the server proceeds to the group check.

The group precedence check is TRUE if the requesting user’s group matches a group record in the ACL. The requesting user is allowed or denied access to the resource based on the permissions defined in that group record. If neither the user precedence check nor the group precedence check is TRUE, then universal permissions are checked to determine access.

When a TRUE precedence is found in the ACL, the requesting user is given or denied access to the resource based on the access being requested and the permissions defined for the TRUE precedence level. For example, if the user is requesting Read access to the resource, and the owner created an ACL on the resource for the user that grants Read permission only, then Read access is allowed. However, if the same user requests Write access to the resource, access is denied. When a precedence check for an ACL is FALSE, indicating that no ACL record exists for the precedence level check, then the evaluation proceeds to the next precedence level until a precedence level evaluates to TRUE, or all levels are checked.

The ability to define permissions that deny access to specific users is useful when you want to allow access to a resource to all members in a group except for one particular member. This can be done by creating an ACL on the resource that grants the group Read permission to the resource. Then, modifying the ACL to deny Read permission to the particular member. Because the user precedence check is performed before the group precedence check, the denied member will be TRUE and he or she will be denied access. The other group members will not match the user ACL precedence, checking FALSE, and will proceed to the group precedence check, which will be TRUE. They will have group Read permission to the resource. UNIX File System permissions cannot prohibit a particular user from having group access to a file.

The key thing to remember is that the server uses the first TRUE precedence record to determine access to the resource. Universal permissions do not necessarily grant access to everyone. If a user is denied access before the evaluation proceeds to the universal access level, the user will not be granted the universal access.