Understanding how the LPRM selects an ACL entry from an ACL

Edit online

When an LP command is run, execution of that command can involve performing several class and resource operations. Before each operation is performed, the LPRM consults the appropriate ACL to determine if the user has permission to perform the operation. The ACL consulted depends on the type of operation, as discussed previously.

When the access list of an ACL is used to determine if a user has permission to perform an operation, one ACL entry is selected. The permission granted by the selected ACL entry determines if the user is permitted to perform the operation. Let's consider how the ACL entry is selected by the LPRM.

While considering how the LPRM selects an ACL entry, keep in mind that an authenticated RMC client has a network identity, and may have a mapped identity.

The network identity is the security-mechanism specific way of identifying the user. For example, host:user01@nodeA.network is the host based authentication (HBA) security mechanism network identity for user user01 on the node with host name nodeA.network, when the user has connected remotely from nodeA to the RMC daemon on some other node.

The authenticated RMC client may have a mapped identity. A mapped identity is a mapping from a network identity to a local user name. For example, none:root represents the mapped root user in ACL entries. See Understanding native identity mapping for more information.

Also keep in mind that, in some circumstances, a client may be unauthenticated. If the client is unauthenticated, ACL entry selection is simple. If the UNAUTHENT ACL entry exists, that entry's permissions determine whether the client can perform the operation. If the UNAUTHENT ACL entry does not exist, permission to perform the operation is denied.

To select an ACL entry for an authenticated client, the LPRM:
  1. Looks for an ACL entry that exactly matches the client's network identity. If such an ACL entry is found, the permissions in that entry determine whether the user has permission to perform the operation. If no such ACL entry is found, proceed to the next step.
  2. Looks through the wildcarded ACL entries for the security mechanism through which the client has been authenticated. The entries are searched in order of appearance in the ACL. The first match is used. Wildcarded ACL entries for the HBA security mechanism specify a host (with no user) or specify all hosts ("*").

    If such an ACL entry is found, the permissions in that entry determine whether the user has permission to perform the operation.

    If no such ACL entry is found, proceed to the next step.

  3. If the client has a mapped identity, looks for an ACL entry that exactly matches the client's mapped identity.

    If such an ACL entry is found, the permissions in that entry determine whether the user has permission to perform the operation.

    If no such ACL entry is found, permission to perform the operation is denied.

If the above procedure used by the LPRM does not result in the selection of an ACL entry, permission to perform the operation is denied.

Example: The following commands show the Resource ACL for LP resource rootcmd on node ms_node. 
[root@ms_node]# lslpracl rootcmd
Resource ACLs for LPRM
Name    Identity              Permissions NodeName            
rootcmd host:root@LOCALHOST   rwa         ms_node.network 
rootcmd host:user01@LOCALHOST rx          ms_node.network 
rootcmd host:user03@LOCALHOST 0           ms_node.network 
rootcmd host:LOCALHOST        r           ms_node.network

Now we will consider what happens when three users attempt to list and execute the LP resource rootcmd.

First, the user user01 tries it. 
[user01@ms_node]# lslpcmd rootcmd
Name = rootcmd
ActivePeerDomain =
CheckSum = 3645744851
CommandPath = /usr/local/bin/root_command
ControlFlags = 1
Description =
FilterArg =
FilterScript =
Lock = 0
NodeNameList = {ms_node.network}
RunCmdName = rootcmd

[user01@ms_node]# runlpcmd -N rootcmd
You just ran a command requiring root authority on ms_node.network
RC = 0

The user user01 is able to both list and execute the resource. The Resource ACL contains an entry for host:user01@LOCALHOST that grants the needed permissions, r and x.

Next, the user user02 tries it. 
[user02@ms_node]# lslpcmd rootcmd
Name = rootcmd
ActivePeerDomain =
CheckSum = 3645744851
CommandPath = /usr/local/bin/root_command
ControlFlags = 1
Description =
FilterArg =
FilterScript =
Lock = 0
NodeNameList = {ms_node.network}
RunCmdName = rootcmd

[user02@ms_node]# runlpcmd -N rootcmd
2610-440 Permission is denied to access a resource specified in this command.
Network Identity user02@0x3ea9ab8f7d18ea6e requires 'x' permission for the re
source '0x6040 0xffff 0x3ea9ab8f 0x7d18ea6e 0x0f6b6d2c 0x4dae62b0' of class I
BM.LPCommands on node ms_node.network.
The user user02 is able to list the LP resource, but not to execute it. The Resource ACL does not contain an entry specific to user02. However, it does contain a matching wildcarded HBA ACL entry, host:LOCALHOST. This ACL entry grants user02 r permission, but not x permission.
Finally, the user user03 tries it. 
[user03@ms_node]# lslpcmd rootcmd

2610-440 Permission is denied to access a resource specified in this command.
Network Identity user03@0x3ea9ab8f7d18ea6e requires 'q' permission for the re
source '0x6040 0xffff 0x3ea9ab8f 0x7d18ea6e 0x0f6b6d2c 0x4dae62b0' of class I
BM.LPCommands on node ms_node.network.

[user03@ms_node]# runlpcmd -N rootcmd
2610-440 Permission is denied to access a resource specified in this command.
Network Identity user03@0x3ea9ab8f7d18ea6e requires 'x' permission for the re
source '0x6040 0xffff 0x3ea9ab8f 0x7d18ea6e 0x0f6b6d2c 0x4dae62b0' of class I
BM.LPCommands on node ms_node.network.
The user user03 is not able to list or execute the LP resource. The Resource ACL contains an entry for host:user03@LOCALHOST. That entry denies all permission to the resource.