Software Distributor (SD-UX) Administration Guide HP-UX 11i v1, 11i v2, and 11i v3 (762797-001, March 2014)

1. Establish the group swadm on the controller host as described above.
2. Edit the three host ACLs on each target system. If you used the suggested setup discussed in
“Setting Up Remote Operations” (page 121) to install the agents on the target systems, you
may edit the three host ACLs on the Targets as superuser on the system from which you
performed setup:
swacl -l host \
-M group:swadm@`hostname`:a @ remsys1. . .remsysN
swacl -l global_soc_template \
-M group:swadm@`hostname`:a @ remsys1. . .remsysN
swacl -l global_product_template \
-M group:swadm@`hostname`:a @ remsys1. . .remsysN
You may want to grant permissions to specific users to manage particular products on the primary
depot. For example, user ramon may be assigned responsibility to manage the ALLBASE product
on your depot, installing new versions and patches when they become available. To add ramon
to the ACL for ALLBASE on the local depot and grant him all permissions on that one product, run
the command:
swacl -l product -M user:ramon:a ALLBASE
At the same time, you may want to eliminate the ACL entry for group swadm for the same product:
swacl -l product -D group:swadm ALLBASE
Security in Local Distributions
Host administrators may grant permission to individual users or groups, trusted at the local host,
to administer software locally. Trusted local users have root ACL entries granting insert and write
permissions. At the source depot, access to all software products is allowed by unrestricted read
access to hosts, depots, and products. This is the basis of a pull model of software distribution.
Restricting Installation to Specific Target Systems by Specific Users
Managers of software source depots may leave software openly installable, as described above,
or may choose to limit distribution to specific systems. ACLs protecting source depot products may
contain entries that restrict product read access to only specified systems, allowing installation only
to those systems. This restriction applies to both the push and pull models.
Below is a sample product ACL that restricts read permission to systemA and systemB and grants
all permissions to user swadm:
user:swadm:rwict
host:systemA.loc.company.com:r
host:systemB.fc.hp.com:r
Security for Software Developers
Software developers iteratively package their products and test them before distribution. This
involves packaging products into depots and installing them to Roots for testing. Since it may
require several iterations to get all the customization right, it is not helpful to prevent software
developers from having free access to depots and Roots for this testing.
You should also not have products that are being tested, coming and going on wide-use depots
and roots. They might accidentally be installed or used before they are ready.
The recommended method of development is to provide one or more development depots and
roots for testing purposes, each with protections customized to meet the needs of the development
group using them. To this end, the default ACL template mechanism described previously is handy,
since products come and go quickly.
A host administrator (someone with insert permission on the host) should create the test depot for
developers, then assign a depot administrator and edit the depot ACL to grant that person control
(ACL edit) permission on the depot. The depot’s product ACL template should then be set up so
162 SD-UX Security