Processing ACLs

To process an ACL, the module iterates through the entries (ACEs) in the list. Note that the LDAP server may return an ACL's entries in any order, so do not assume the order of entries has any effect on the outcome. For each entry:

• • if this entry applies to this user
    • if this is an allow rule
      • if this is a higher-ranked rule than any we have processed so far
        • reset the current allowed-access level and permission set for the user
      • for each action specified in the entry
        • if this specifies a higher level of access
          • update the user's allowed-access level
        • add the specified action to the user's allowed-permissions set
    • else (this is a deny rule)
      • if this is a higher-ranked rule than any we have processed so far
        • reset the current denied-access level and permission set for the user
      • for each action specified in the entry
        • if this specifies a lower level of access
          • update the user's denied-access level
        • add the specified action to the user's denied-permissions set
  • if this entry applies to an applicable group
    • do the same as above, but updating group-allow and group-deny variables

After processing all of the ACL:

• if no applicable entries were found, continue on with the next rule
• if this is an AUTH (MTO resource, mainframe-style access levels) request
  • if group entries were found but no user entries, use the group entries
  • if user entries were found but no group entries, or the user entries are at the same or higher rank than the group entries, use the user entries
  • if this is an access request
    • if there are deny entries at the same or higher rank than the allow entries, and the deny level is less than or equal to the requested level
      • deny the request
    • else if the requested level is greater than the allowed level
      • deny the request
    • else
      • allow the request
  • else (this is a permissions query)
    • if there are deny entries at the same or higher rank than the allow entries
      • reduce the allowed level to one below the lowest denied level (eg if update is denied, reduce the allowed level to read)
    • return the allowed level
• else (this is an XAUTH, MFDS resource, permissions-set request)
  • compare the ranks of user-allow, user-deny, group-allow, and group-deny permissions
  • the highest of the four determines whether user rules outrank group rules, or vice versa (if user and group are equal rank, user wins)
  • compute the final set of permissions as
    • add lower-ranked allowed permissions
    • remove lower-ranked denied permissions
    • add higher-ranked allowed permissions
    • remove higher-ranked denied permissions
  • if this is an access request
    • if the requested permissions are all in the result set
      • allow the request
    • else
      • deny the request
    • else (this is a permissions query)
      • return the result set

In other words, access-level requests first decide whether user or group rules should apply (based on rank), then determine the level that results from those rules, then return the appropriate result based on that level.

Permissions-set requests start with the lower-ranked rules, then allow the higher-ranked rules to override them, to determine the final effective set of permissions.