swacl.1m (2012 03)

s
swacl(1M) swacl(1M)
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 pro-
duct level read access via either a
host, other,orany_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:[e-mail]:-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 com-
ment 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
.)
Entries With IPv6 Addresses
IPv6 addresses in the keys within the ACL entries are not allowed.
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 follow-
ing permissions may be granted:
r ead Grants permission to read the object. On host, depot,or root objects, read per-
mission 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 (for example, installed root filesystem), this also grants permis-
sion 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
HP-UX 11i Version 3: March 2012 − 7 − Hewlett-Packard Company 7