Basic Security Tasks

Listing User Access

The following examples show how to list users with access to depots, targets host, target root, and all products.

Allowing Users to Manage Products in a Depot

Users that are packaging products may need access to the SD-UX depots to store their products.

In ACLs, a is a shorthand notation for all permissions (crwit).

To allow user mary to add new products to the depot:

swacl -l depot -M user:mary:a [@ host:depot]

To allow access for user mary to modify all existing products in a depot:

swacl -l product -M user:mary:a \* [@ host]

To modify the template so that user mary can modify new products created by others in the depot:

swacl -l global_product_template -M user:mary:a [@ host]

(In the above examples, change user to group and use a group name to add group access to the depot structures.)

Allowing Users to Manage Roots (Install/Remove)

To give a user (mary) the necessary permissions to be able to install or remove software on host mysys:

swacl -l root -M user:mary:a @ mysys

To allow user mary to install software into the default root:

swacl -l root -M user:mary:ri

To give user mary the permission to open the root for reading:

swacl -l root -M user:mary:r

To give user mary the permission to install new software into the root object:

swacl -l root -M user:mary:i

To let remote user allen@swelter fully manage the root file system on swcrunch:

swacl -l root -M user:allen@swelter:a

(In the above examples, change user to group and use a group name to add group access to the depot structures.)

	NOTE: Because software installation usually involves modification of system files during configurations, software install and configure scripts are run as the superuser. Therefore, granting a user write permission on a root is essentially giving them superuser access for managing software.

Restricting Access to Depots

To restrict read access to a depot you must first remove any_other access from the depot and from the products contained in the depot and the template controlling the products in the depot.

You can restrict access to depot alpine on host drgw:

You will then need to add specific users (and then hosts) with read access after removing any_other from the depot security. The following commands add read access for any user on hostA to the depot, the products contained in the depot, and future products, respectively.

In the following example, the local superuser disallows all remote users from accessing /simple_1.depot on swelter, but allow local users to access the depot:

Local users can now access this depot as a result of the other ACL, but remote users are refused.

To allow only user shelly on host swcrunch to access software in a depot located on swelter, it may appear that adding a user ACL for shelly would be sufficient:

swacl -l depot -M user:shelly@swcrunch:r @ /simple_1.depot

However, this is not enough. An attempt by shelly to access this depot would fail with a security violation. This is because SD-UX also requires that SD agents (the swagent process) that contacts the depot server to be authorized via a host ACL entry_type:

swacl -l depot -M host:swcrunch:r @ /simple_1.depot

(Note that user shelly also requires appropriate ACL permission to install software on swcrunch.)

	NOTE: The r (read) permission allows the user to access the depot and products, and the t (test) permission allows the user to list the ACLs.

Adding Target Hosts

For swinstall and swcopy, both the user and target host are validated (i.e., to protect from unauthorized users at remote hosts switching to an authorized user). The following adds read permission for the host named target to the default depot on the local host, the products currently in the depot, and any future products added to the depot (using global_product_template).

Since the user is always validated, another alternative that makes it easier to manage large numbers of hosts is to allow all hosts read permission:

	NOTE: “*” is only a supported value for the host ACL type.

Temporarily Restricting Access

A simple method of restricting access to anyone other than the local superuser without modifying ACLs is to unregister the depot.

swreg -u -l depot [@ depot]

It can then be reregistered later:

swreg -l depot [@ depot]

Closing the SD-UX Network

The SD-UX secret is used as evidence of trustworthiness for the caller’s credentials. It is a password that SD-UX uses to check the authenticity of the caller’s host. The default secret field is set by manufacturing to match the default setting on the HP-UX controller. All secrets (i.e., controller, targets, and depots) must be identical.

	NOTE: Do not change the default secret field unless you have also changed the default secret on the HP-UX SD-UX controller. These two secrets must match.

The set of hosts that can be managed by SD-UX can be restricted by changing the default secret on all SD-UX controller and target hosts in the network. The default secret is found in /var/adm/sw/security/secrets.

You may change the default secret found in this file:

default      new secret

For additional information, see “Security Between Hosts: The Shared Secrets File ”.

Editing an ACL

The swacl command, when invoked without the -M, -D, or -F options, reads the specified ACL, converts it into plain text and prints it to stdout. The output of the command can also be redirected to a file, which can then be printed or edited. After editing, you can use the -F file option described above to replace the entire old ACL. This procedure gives you full ACL editing capabilities.

You must have test permission within the ACL to produce the edit file (list the ACL) and control permission to modify it with -F, -D, or -M options. All ACL entries must contain test permission.

If the replacement ACL contains no detectable errors and you have the proper permission on the ACL, the replacement will succeed. If the replacement fails because you lack permission to make the change, an error is generated, and the object is skipped.

You may change or delete existing entries, or you may add additional entries to the ACL.

	NOTE: It is possible to edit an ACL so that you cannot access it! Caution should be used to avoid accidentally removing your own control (c) permissions on an ACL. As a safeguard, the local superuser may always use swacl to edit SD-UX ACLs.

Here are some examples based on the following ACL that is protecting a product (FORTRAN) created by user rob whose local host is lehi.fc.hp.com:

You can list the ACLs for the product is FORTRAN in depot /var/spool/sw (the default depot) and prepare it for editing:

This will bring the above ACL into the file acl_tmp, and it is ready for editing. Edit the acl_tmp file with any suitable text editor.

To replace all entries in the ACL for FORTRAN, type:

To edit the default product template on a depot /var/spool/sw_dev, use:

# swacl -l product_template @ /var/spool/sw_dev >tmp_file

Then edit the tmp_file and replace the ACL:

# swacl -l product_template -F tmp_file \
      @ /var/spool/sw_dev

To delete entries for user barb and group swadm, use:

To give user ramon permission to modify the product FORTRAN, type:

# swacl -M user:ramon:trw -l product FORTRAN

To add an entry for user pam with complete management permission (“a” is shorthand for crwit), use:

# swacl -M user:pam:a  

To add an entry to grant every user in group swadm at remote hosts dewd and stewd full management control of the product FORTRAN on the default local depot, use the following:

To list the ACL protecting the default depot at host dewd, type: