Software Distributor Administration Guide HP-UX 11i v1, 11i v2, and 11i v3 (5900-2561, March 2013)

9.7.1.1 Controllers Run with the User’s Credentials and Privileges
SD-UX controller programs such as swinstall or swremove operate with the privileges of the
user who invokes them. The agent ensures that the user has the required permissions on the object
by looking at the object’s ACL. If permissions are not granted, the operation fails.
A controller may be run by anyone on the system, but its actions are restricted (based on permissions
granted in various object ACLs). SD-UX agents always verify that user-requested operations are
authorized before performing them.
9.7.1.2 Agents Run with the System’s Identity
The SD-UX agents and daemons run with the privileges of a superuser; but they also have the
special identity of the host system on which they are executing. When a target agent makes an
RPC call to a source agent, two sets of credentials are passed with the call:
• those of the agent’s system
• those of the user running the controller on whose behalf the target agent runs
While local superuser privilege is necessary for the agent to do required local file system operations
such as file creation and deletion, ACL management, etc., this level of permission is neither required
nor desired for DCE RPC operations with other SD-UX processes.
When SD-UX agents perform RPCs, they assume the identity of the system on which they run, rather
than that of a particular user.
9.7.2 Security Between Hosts: The Shared Secrets File
In addition to the caller’s credentials, other evidence of trustworthiness is also sent in the RPC. The
SD-UX agent checks this evidence before accepting the caller credentials. This evidence consists
of passing the encryption of a secret password. The password is read from the shared secrets file.
This file is located on systems in /var/adm/sw/security/secrets.
NOTE: The SD-UX Secret must be the same on both the target system and the controller.
The agent compares this encrypted secret to the encryption of a local secret it shares with the
controller’s host. If the secrets do not match, the call is not authenticated and it fails.
Secrets are stored by host name in the secrets file and are used to establish trust between two
systems. The controller selects a secret in the file that corresponds with the host name of the system
on which it is running. The agent, upon receipt of an RPC from the controller, looks up a secret
associated with the controller’s host.
For example, if the controller is running on alma.fc.hp.com and makes a request of an agent
running on lehi.fc.hp.com, each of the two processes will look up the secret associated with
alma.fc.hp.com (the controller’s host) from their respective secrets file.
Here is an example of the format of the shared secrets file:
default quicksilver
lehi.fc.hp.com s28ckjd9
alma.fc.hp.com 32hwt
newdist.fc.hp.com zztop
noway.fc.hp.com daisey
The first column represents the controller’s host name and the second column represents the
controller’s secret.
There is also a provision for a default secret (quicksilver in the example above), to be used
when no system name match is found in the secrets file. The entry is identified with the default
pseudo-host name. This entry allows open SD-UX interconnect between hosts sharing the same
default entry. SD-UX is shipped with the secret -sdu- that should be changed for your site.
9.7 SD-UX Internal Authentication 163