swacl(1M)

NAME

swacl — view or modify the Access Control Lists (ACLs) which protect software products

SYNOPSIS

swacl -l level [-D acl_entry| -F acl_file| -M acl_entry] [-f software_file] [-t target_file] [-x option=value] [-X option_file] [software_selections] [@ target_selections]

Remarks

This command supports operations on remote systems. See the Remote Operation section below for details.
Type man 5 sd to display sd(5) for an overview of all SD commands.

DESCRIPTION

The swacl command displays or modifies the Access Control Lists (ACLs) which:

Protect the specified target_selections (hosts, software depots or root filesystems).
Protect the specified software_selections on each of the specified target_selections (software depots only).

All root filesystems, software depots, and products in software depots are protected by ACLs. The SD commands permit or prevent specific operations based on whether the ACLs on these objects permit the operation. The swacl command is used to view, edit, and manage these ACLs. The ACL must exist and the user must have the appropriate permission (granted by the ACL itself) in order to modify it.

ACLs offer a greater degree of selectivity than standard file permissions. ACLs allow an object's owner (i.e. the user who created the object) or the local superuser to define specific read, write, or modify permissions to a specific list of users, groups, or combinations thereof.

Some operations allowed by ACLs are run as local superuser. Because files are loaded and scripts are run as superuser, granting a user write permission on a root filesystem or insert permission on a host effectively gives that user superuser privileges.

Protected Objects

The following objects are protected by ACLs:

Each host system on which software is being managed by SD,
Each root filesystem on a host (including alternate roots),
Each software depot on a host,
Each software product contained within a depot.

Remote Operation

You can enable SD to manage software on remote systems. To let the root user from a central SD controller (also called the central management server or manager node) perform operations on a remote target (also called the host or agent):

1)

Set up the root, host, and template Access Control Lists (ACLs) on the remote machines to permit root access from the controller system. To do this, run the following command on each remote system:

/usr/lib/sw/mx/setaccess controller

NOTES:

controller is the name of the central management server.
If remote system is 11.00, make sure SD patch PHCO_22526 or a superseding patch is installed on remote system before running setaccess.
If remote system is older than 11.00 or for some other reason does not have setaccess in place, copy setaccess script from an 11.11 or higher system to the remote system.

2)

swinstall, swcopy, and swremove have enhanced GUI interfaces for remote operations. Enable the enhanced GUIs by creating the .sdkey file on the controller. Use this command:

touch /var/adm/sw/.sdkey

See sd(5), swinstall(1M), swcopy(1M), swjob(1M), swlist(1M) or swremove(1M) for more information on interactive operations.

NOTE: You can also set up remote access by using swacl directly on the remote machines to grant root or non-root access to users from the controller system.

Options

If the -D, -F, or -M option is not specified, swacl prints the requested ACL(s) to the standard output.

The swacl command supports the following options:

-D acl_entry

Deletes an existing entry from the ACL associated with the specified object(s). For this option, the permission field of the ACL entry is not required. You can specify multiple -D options. See the ACL Entries heading for more information.

-f software_file

Read the list of software_selections from software_file instead of (or in addition to) the command line.

-F acl_file

Assigns the ACL contained in acl_file to the object. All existing entries are removed and replaced by the entries in the file. Only the ACL's entries are replaced; none of the information contained in the comment portion (lines with the prefix #) of an ACL listing is modified with this option. The acl_file is usually the edited output of a swacl list operation.

If the replacement ACL contains no syntax errors and the user has control permission on the ACL (or is the local superuser), the replacement succeeds.

-l level

Defines which level of SD ACLs to view/modify.

The supported levels of depot, host, root, and product objects that can be protected are:

depot: View/modify the ACL protecting the software depot(s) identified by the target_selections.
host: View/modify the ACL protecting the host system(s) identified by the target_selections.
root: View/modify the ACL protecting the root filesystem(s) identified by the target_selections.
product: View/modify the ACL protecting the software product identified by the software_selection. Applies only to products in depots, not installed products in roots.

The supported levels of templates are:

global_soc_template: View/modify the template ACL used to initialize the ACL(s) of future software depot(s) or root filesystem(s) added to the host(s) identified by the target_selections. Additionally, swacl can create templates that you can re-use to create new ACLs.
global_product_template: View/modify the template ACL used to initialize the product_template ACL(s) of future software depot(s) added to the host(s) identified by the target_selections.
product_template: View/modify the template ACL used to initialize the ACL(s) of future product(s) added to the software depot(s) identified by the target_selections.

-M acl_entry

Adds a new ACL entry or changes the permissions of an existing entry. You can specify multiple -M options. See the ACL Entries heading for more information.

-t target_file

Read the list of target_selections from file instead of (or in addition to) the command line.

-x option=value

Set the session option to value and override the default value (or a value in an alternate option_file specified with the -X option). You can specify multiple -x options.

-X option_file

Read the session options and behaviors from option_file.

You can specify only one of the -D, -F, or -M options at each invocation of swacl.

Operands

Most SD commands support two types of operands: software selections followed by target selections. These operands are separated by the "at" (@) character. This syntax implies that the command operates on "software selections at targets".

Software Selections

The swacl command supports the following syntax for each software_selection:

product[,version] 

The = (equals) relational operator lets you specify selections with the following shell wildcard and pattern-matching notations:
- [ ], *, ?
The \* software specification selects all products in the depot when used with -l product.

The version component usually has the following form:

[,r <op> revision][,a <op> arch][,v <op> vendor] 
[,c <op> category] 

The <op> (relational operator) component can take the form:
- =, ==, >=, <=, <, >, or !=
which performs individual comparisons on dot-separated fields.
For example, r>=B.10.00 chooses all revisions greater than or equal to B.10.00. The system compares each dot-separated field to find matches. Shell patterns are not allowed with these operators.
The = (equals) relational operator lets you specify selections with the shell wildcard and pattern-matching notations:
- [ ], *, ?, !
For example, the expression r=1[01].* returns any revision in version 10 or version 11.
All version components are repeatable within a single specification (e.g. r>=A.12, r<A.20). If multiple components are used, the selection must match all components.
Fully qualified software specs include the r=, a=, and v= version components even if they contain empty strings.
No space or tab characters are allowed in a software selection.
The software instance_id can take the place of the version component. It has the form:
- [instance_id]
within the context of an exported catalog, where instance_id is an integer that distinguishes versions of products and bundles with the same tag.

Target Selections

The SD commands support this syntax for each target_selection.

[host][:][/directory]

The colon (:) is required if both a host and directory are specified.

EXTERNAL INFLUENCES

Default Options

In addition to the standard options, you can change SD behaviors and policy options by editing the default values found in:

/var/adm/sw/defaults: the system-wide default values,
$HOME/.swdefaults: the user-specific default values.

You must use the following syntax to specify values in the defaults file:

[command_name.]option=value 

The optional command_name prefix denotes one of the SD commands. Using the prefix limits the change in the default value to that command. If you leave the prefix off, the change applies to all commands.

You can also override default values from the command line with the -x or -X options:

command -x option=value

command -X option_file

The following section lists all of the keywords supported by the swacl command. If a default value exists, it is listed after the =.

admin_directory=/var/adm/sw (for normal mode)

admin_directory=/var/home/LOGNAME/sw (for nonprivileged mode)

The location for SD logfiles and the default parent directory for the installed software catalog. The default value is /var/adm/sw for normal SD operations. When SD operates in nonprivileged mode (that is, when the run_as_superuser default option is set to true):

The default value is forced to /var/home/LOGNAME/sw
The path element LOGNAME is replaced with the name of the invoking user, which SD reads from the system password file.
If you set the value of this option to HOME/ path, SD replaces HOME with the invoking user's home directory (from the system password file) and resolves path relative to that directory. For example, HOME/my_admin resolves to the my_admin directory in your home directory.
If you set the value of the installed_software_catalog default option to a relative path, that path is resolved relative to the value of this option.

SD's nonprivileged mode is intended only for managing applications that are specially designed and packaged. You cannot use this mode to manage the HP-UX operating system or patches to it. For a full explanation of nonprivileged SD, see the Software Distributor Administration Guide, available at the http://docs.hp.com web site.

See also the installed_software_catalog and run_as_superuser options.

distribution_target_directory=/var/spool/sw

Defines the default location of the target depot.

installed_software_catalog=products

Defines the directory path where the Installed Products Database (IPD) is stored. This information describes installed software. When set to an absolute path, this option defines the location of the IPD. When this option contains a relative path, the SD controller appends the value to the value specified by the admin_directory option to determine the path to the IPD. For alternate roots, this path is resolved relative to the location of the alternate root. This option does not affect where software is installed, only the IPD location.

This option permits the simultaneous installation and removal of multiple software applications by multiple users or multiple processes, with each application or group of applications using a different IPD.

Caution: use a specific installed_software_catalog to manage a specific application. SD does not support multiple descriptions of the same application in multiple IPDs.

See also the admin_directory and run_as_superuser options, which control SD's nonprivileged mode. (This mode is intended only for managing applications that are specially designed and packaged. You cannot use this mode to manage the HP-UX operating system or patches to it. For a full explanation of nonprivileged SD, see the Software Distributor Administration Guide, available at the http://docs.hp.com web site.)

level=

Defines the level of SD ACLS to view/modify. The supported levels are: host, depot, root, product, product_template, global_soc_template, or global_product_template.

See the discussion of the -l option above for more information.

rpc_binding_info=ncacn_ip_tcp:[2121] ncadg_ip_udp:[2121]

Defines the protocol sequence(s) and endpoint(s) on which the daemon listens and which the other commands use to contact the daemon. If the connection fails for one protocol sequence, the next is attempted. SD supports both the tcp (ncacn_ip_tcp:[2121]) and udp (ncadg_ip_udp:[2121]) protocol sequence on most platforms.

rpc_timeout=5

Relative length of the communications timeout. This is a value in the range from 0 to 9 and is interpreted by the DCE RPC. Higher values mean longer times; you may need a higher value for a slow or busy network. Lower values will give faster recognition on attempts to contact hosts that are not up, or are not running swagentd. Each value is approximately twice as long as the preceding value. A value of 5 is about 30 seconds for the ncadg_ip_udp protocol sequence. This option may not have any noticeable impact when using the ncacn_ip_tcp protocol sequence.

run_as_superuser=true

This option controls SD's nonprivileged mode. This option is ignored (treated as true) when the invoking user is super-user.

When set to the default value of true, SD operations are performed normally, with permissions for operations either granted to a local super-user or set by SD ACLs. (See swacl(1M) for details on ACLs.)

When set to false and the invoking user is local and is not super-user, nonprivileged mode is invoked:

Permissions for operations are based on the user's file system permissions.
SD ACLs are ignored.
Files created by SD have the uid and gid of the invoking user, and the mode of created files is set according to the invoking user's umask.

See also the admin_directory and installed_software_catalog options.

select_local=true

If no target_selections are specified, select the default target_directory of the local host as the target_selection for the command.

software=

Defines the default software_selections. There is no supplied default. If there is more than one software selection, they must be separated by spaces.

targets=

Defines the default target_selections. There is no supplied default (see select_local above). If there is more than one target selection, they must be separated by spaces.

verbose=1

Controls the verbosity of the output (stdout). A value of:

0: disables output to stdout. (Error and warning messages are always written to stderr).
1: enables verbose messaging to stdout.

Environment Variables

SD programs are affected by external environment variables, set environment variables for use by the control scripts, and use other environment variables that affect command behavior.

The external environment variable that affects the swacl command is:

LANG

Determines the language in which messages are displayed. If LANG is not specified or is set to the empty string, a default value of C is used. See the lang(5) man page by typing man 5 lang for more information.

Note: The language in which the SD agent and daemon log messages are displayed is set by the system configuration variable script, /etc/rc.config.d/LANG. For example, /etc/rc.config.d/LANG, must be set to LANG=ja_JP.SJIS or LANG=ja_JP.eucJP to make the agent and daemon log messages display in Japanese.

LC_ALL

Determines the locale used to override any values for locale categories specified by the settings of LANG or any environment variables beginning with LC_.

LC_CTYPE

Determines the interpretation of sequences of bytes of text data as characters (e.g., single-versus multibyte characters in values for vendor-defined attributes).

LC_MESSAGES

Determines the language in which messages are written.

LC_TIME

Determines the format of dates (create_date and mod_date) when displayed by swlist. Used by all utilities when displaying dates and times in stdout, stderr, and logging.

TZ

Determines the time zone for use when displaying dates and times.

OPERATION

ACL Entries

Each entry in an ACL has the following form:

entry_type[:key]:permissions
For example: user:steve@newdist:crwit

An ACL can contain multiple entries. See the Entry Types and Permissions headings below for more information.

Entry Types

The following entry_types are supported:

any_other: Permissions for all other users and hosts that do not match a more specific entry in the ACL. (Example: any_other:-r--t.)
group: Permissions for a named group. This type of ACL entry must include a key that identifies that group. The format can be: group:group_name:permissions or group:group_name @hostname: permissions. (Example: group:adm:crwit.)
host: Permissions for an SD agent from the specified host system. SD agents require product level read access via either a host, other, or any_other entry type in order to copy or install products from depots. This type of ACL entry must include a key containing a hostname or number (in Internet dot notation) of a system or the asterisk character (*) to denote all systems. (Example: host:newdist@fc.hp.com:-r--t.)
object_owner: Permissions for the object's owner, whose identity is listed in the comment header. (Example: object_owner:crwit.)
object_group: Permissions for members of the object's group, whose identity is listed in the comment header. (Example: object_group:crwit.)
other: Permissions for others who are not otherwise named by a more specific entry type. The format for other can be: other:permissions for others on the local host (only one such entry allowed) or other: @hostname:permissions for others at remote hosts (Only one such entry per remote host allowed). (Example: other:@newdist:-r--t.)
user: Permissions for a named user. This type of ACL entry must include a key that identifies that user. The format for user can be: user:user_name:permissions or user:user_name @hostname: permissions. (Example: user:rml:crwit.)

Permissions

Permissions are represented as the single character abbreviations indicated below. Some permissions either apply only to, or have different meaning for, certain types of objects, as detailed below. The following permissions may be granted:

r ead

Grants permission to read the object. On host, depot, or root objects, read permission allows swlist operations. On products within depots, read permission allows product files to be installed or copied with swinstall or swcopy.

w rite

Grants permission to modify the object itself.

On a root object (e.g. installed root filesystem), this also grants permission to modify the products installed (contained) within it.
On a depot object, it does not grant permission to modify the products contained within it. Write access on products is required to modify products in a depot.
On a host container, write permission grants permission to unregister depots. It does not grant permission to modify the depots or roots contained within it.

i nsert

On a host object, grants permission to create (insert) a new software depot or root filesystem object, and to register roots and depots. On a depot object, grants permission to create (insert) a new product object into the depot.

c ontrol

Grants permission to modify the ACL using swacl.

t est

Grants permission to perform access checks and to list the ACL.

a ll

A wildcard which grants all of the above permissions. It is expanded by swacl to crwit.

List Output Format

The output of a list operation is in the following format:

# swacl   Object_type     Access Control List
# 
# For     depot|host:[host]:[/directory]
# 
# Date:   date_stamp
# 
# Object Ownership:  User=  user_name
#                    Group= group_name
#                    Realm= host_name
# 
# default_realm = host_name
entry_type:[key:]permissions
entry_type:[key:]permissions
entry_type:[key:]permissions

You can save this output into a file, modified it, then use it as input to a swacl modify operation (see the -F option above).

Object Ownership

An owner is also associated with every SD object, as defined by the user name, group and hostname. The owner is the user who created the object. When using swacl to view an ACL, the owner is printed as a comment in the header.

Default Realm

An ACL defines a default realm for an object. The realm is currently defined as the name of the host system on which the object resides. When using swacl to view an ACL, the default realm is printed as a comment in the header.

Keys

Expressions (patterns) are not permitted in keys.

A key is required for user, group and host entry types. A key is optional for other entry types, and specifies the hostname to which the entry applies. Only one other entry type may exist without a key, and this entry applies to users at the default realm (host) of the ACL.

A hostname in a key is listed in its Internet address format (dot notation) if swacl cannot resolve the address using the local lookup mechanism (DNS, NIS, or /etc/hosts). A hostname within an ACL entry must be resolvable when used with the -D and -M options. Unresolvable hostname values are accepted in files provided with the -F option.

RETURN VALUE

The swacl command returns:

0: The software_selections and/or target_selections were successfully displayed or modified.
1: The display/modify operation failed on all target_selections.
2: The modify/modify operation failed on some target_selections.

DIAGNOSTICS

The swacl command writes to stdout, stderr, and to the daemon logfile.

Standard Output

The swacl command prints ACL information to stdout when the user requests an ACL listing.

Standard Error

The swacl command writes messages for all WARNING and ERROR conditions to stderr. A report that the software_selections do not exist is also given if the user has no access permissions to the object.

Logging

The swacl command does not log summary events. It logs events about each ACL which is modified to the swagentd logfile associated with each target_selection.

swagentd Disabled

If the swagentd daemon has been disabled on the host, it can be enabled by the host's system administrator by setting the SW_ENABLE_SWAGENTD entry in /etc/rc.config.d/swconfig to 1 and executing /usr/sbin/swagentd -r.

EXAMPLES

To list the ACLs for the C and OPENVIEW products in depot /var/spool/swtest:

swacl -l product C OPENVIEW  @ /var/spool/swtest 

The ACL listed to the standard output is similar to this example ACL:

# 
# swacl   Product Access Control Lists 
# 
# For depot: newdist:/var/spool/swtest 
# 
# Date:  Wed May 26 11:14:31 2000 
# 
# 
# For product:  OPENVIEW,r=3.2 
# 
# 
# Object Ownership:  User=  robason 
#                    Group= swadm 
#                    Realm= newdist.fc.hp.com 
# 
# default_realm=newdist.fc.hp.com 
object_owner:crwit 
group:swadm:crwit 
any_other:-r--t 
# 
# For product:  C,r=9.4 

# 
# 
# Object Ownership:  User=  robason 
#                    Group= swadm 
#                    Realm= newdist.fc.hp.com 
# 
# default_realm=newdist.fc.hp.com 
object_owner:crwit 
user:rob 
@lehi.fc.hp.com:-r--t 
user:barb:-r--t 
user:ramon:-r--t 
group:swadm:crwit 
other:-r--t 
host:lehi.fc.hp.com:-r--t 

To list the product template ACL on host newdist:

swacl -l global_product_template  @ newdist 

To list the host ACL on the local system:

swacl -l host 

To read, edit, then replace the ACL protecting the default depot /var/spool/sw:

swacl -l depot > new_acl_file 
vi new_acl_file 
swacl -l depot -F new_acl_file 

To allow user allen to create, register, and manage all new depots and roots on the local system:

swacl -l host -M user:allen:a 
swacl -l global_soc_template -M user:allen:a 
swacl -l global_product_template -M user:allen:a 

To allow user allen to fully manage my_depot, which already exists:

swacl -l depot -M user:allen:a @ /my_depot 
swacl -l product_template -M user:allen:a @ /my_depot 
swacl -l product -M user:allen:a \* @ /my_depot 

To deny general access to a depot:

swacl -l depot -M any_other:- @ /restricted_depot 
swacl -l product -M any_other:- \* @ /restricted_depot 
swacl -l product_template -M any_other:- @ /restricted_depot 

To allow user allen on host gemini access to restricted_depot and all products it currently contains:

swacl -l depot -M host:*:rt @ /restricted_depot 
swacl -l depot -M user:allen@gemini:rt @ /restricted_depot 
swacl -l product -M user:allen@gemini:rt \* @ /restricted_depot 

To revoke previously granted ACL permission for user allen on host gemini to access the WDB product in the default depot on lehi:

swacl -l product -D user:allen@gemini WDB @ lehi 

To deny access to the default depot on the local system from host numenal:

swacl -l depot -M host:numenal:- 

To deny access to the OPENVIEW product in the default depot on host lehi to all users who do not have an explicit ACL entry:

swacl -l product -M any_other:t OPENVIEW @ lehi 

To allow user george on host newdist access to the OPENVIEW product in the default depot on host lehi, you must specify both a user ACL for george and a host ACL for newdist:

swacl -l product -M user:george@newdist:rt OPENVIEW @ lehi 
swacl -l product -M host:newdist:rt OPENVIEW @ lehi 

To revoke a user ACL for user allen on host gemini that allowed access to the OPENVIEW product in the default depot on host lehi:

swacl -l product -D user:allen@gemini OPENVIEW @ lehi 

To revoke any previously issued access to the OPENVIEW product in the default depot on host lehi by users on host numenal:

swacl -l product -D host:numenal OPENVIEW @ lehi 

To deny all access to the users steve and george for the depot /var/spool/sw at host newdist:

swacl -l depot -M user:steve:- -M user:george:- \ 
      @ newdist:/var/spool/sw 

To delete entries for local user rick from all products in the default local depot:

swacl -l product -D user:rick \* 

WARNINGS

You can edit an ACL in such a way that it will leave a system inaccessible. Do not remove all control permissions on an ACL. (Note, however, that the local super-user can always edit SD ACLs, regardless of permissions.)
ACLs can grant the equivalent of local superuser permission. SD loads and runs files and scripts as superuser. Therefore, if an SD ACL gives a user write permission on a root filesystem or insert permission on a host, that user has the equivalent of superuser privileges.
Note that swacl is not a general purpose ACL editor. It works only on ACLs protecting SD objects.

FILES

$HOME/.swdefaults: Contains the user-specific default values for some or all SD options.
/usr/lib/sw/sys.defaults: Contains the master list of current SD options (with their default values).
/var/adm/sw/: The directory which contains all of the configurable (and non-configurable) data for SD. This directory is also the default location of logfiles.
/var/adm/sw/defaults: Contains the active system-wide default values for some or all SD options.
/var/adm/sw/products/: The Installed Products Database (IPD), a catalog of all products installed on a system.
/var/adm/sw/security/: The directory which contains ACLs for the system itself, template ACLS, and the secrets file used to authenticate remote requests.
/var/spool/sw/: The default location of a source and target software depot.

AUTHOR

swacl was developed by the Hewlett-Packard Company.