ACL Entries

An ACL consists of a set of entries attached to an object when it is created. These entries define which users, groups, and/or hosts have permission to access the objects. ACL entries include the concept of a principal, which is the user, group or host system (for agents making RPCs) that originates a call to another system.

An ACL entry consists of three fields:

entry_type[:key]:permissions

For example, an ACL entry for an SD-UX object might be:

user:fred:r-ctw

This means that a user named fred can control (c), read (r), write (w), and test (t) the object, but the dash signifies that he cannot i (insert/create) new objects.




	NOTE: You can specify `crwit` permissions in any order.

The ACL entry_type must be one of these values:

Table 9-3 SD-UX ACL Entry Types

Type	Permissions Apply To
`user`	User principal, whose name is to be specified in the `key` field
`group`	Group principal, whose name is to be specified in the `key` field
`host`	Host systems (target agents acting on behalf of users for install or copy)
`other`	Principals with no matching user and group entries
`any_other`	Principals not matching any other entry
`object_owner`	Owner of the object
`object_group`	Members of the group to which an object belongs




	TIP: Do not confuse the host object (which is a computer system that contains depots, roots, and software) with the `host` entry type (which defines permissions for access to target systems).

The user and group of the object’s owner are determined and automatically recorded at the time the object is created (based on the identity of the person who creates it). This information is recorded as user, group, and realm. An object_owner or object_group entry type in an ACL causes the SD-UX ACL manager to look up the owner and group information on the object; and if a match to the requester is found, grant permissions as specified.

There may be many user, group, and host type entries per ACL, while there may be only one of each of object_owner, object_group and any_other. There may be at most one local (i.e., no key) other entry and an unlimited number of remote (i.e., keyed) other entries.

ACL Keys

The second part of the ACL entry is the key. The table below lists the possible key values for specific entry types.

Table 9-4 SD-UX ACL Entry Key Values

Entry Type	Key Content
`user`	a user name [optionally, @ `remote-host`]
`group`	a group name [optionally, @ `remote-host`]
`host`	a host name
`other`	[optionally, @ `remote-host`]
`any_other`	no key allowed

When listing the ACL, the remote-host is printed in its Internet address form (e.g., 15.12.89.10) if the local system cannot resolve the address from its host lookup mechanism (DNS, NIS, or /etc/hosts). The remote-host must be recognized (resolvable) when used in the -M and -D options. Unrecognized remote-host values are accepted in files provided with the -F option.

ACL Permissions

There are five different permissions grantable by the ACL: crwit.

Table 9-5 ACL Permissions

control (`c`)	Permission to edit or change the ACL.
test (`t`)	Permission to test access to an object (i.e., read the ACL).
insert (`i`)	Permission to install a new product, depot or root.
write (`w`)	Permission to change a host, depot, root or product.
read (`r`)	Permission to list depot, roots and products and attributes.

In the ACL entry, these permissions are abbreviated c, t, i, w, and r. To grant all permissions, you may use the shorthand letter a instead of the crwit to denote all permissions.

The meaning of permissions is different for different types of objects, and the permissions do not have to appear in any specific order. Roots do not provide product level protection, so all permissions on products installed on roots are controlled by the ACL protecting the root itself.

Product level protection is provided on depots in this way: the depot’s ACL protects the depot itself while product ACLs protect the products within the depot.

The table below summarizes SD-UX object permissions and ACLs to which they may be applied.

Table 9-6 SD-UX ACL Permission Definitions

Permission	Allows You To:
	Host System	Root	Depot	Product on Depot
`c` (control)	Edit all ACLs
`t` (test)	Test access to an object, read (list) the ACL itself
`i` (insert)	Insert a new depot or root	Insert a new product	Insert a new product	N/A
`w` (write) ^[1]	Change host	Change root or products	Change depot	Change product
`r` (read) ^[2]	List depots and roots	List root and product attributes	List depot and product attributes	Read product files
^[1]Write permission means permission to change or delete the object, except the host source object may not be deleted. ^[2]Read permission on containers (i.e., hosts, roots, and depots) lets a user list the container contents; on products within depots, read permission lets a user copy or install the product.

Object Protection

The control of product insert and delete permissions differs between roots and depots.

The permission for anyone to insert or delete a product on a root is contained within the root’s ACL. If you have write permission on a root, you can change or delete any product on that root; there is NO product level control on roots.

The depot ACL controls insertion (creation) of new products, while the inserted object has its own ACL that controls modification and deletion. This lets the creator (owner) of a product on a depot change or delete the product without requiring the broader write permission that could affect other users’ products on the same depot.

This is useful for product control, because it lets you assign management control for a specific product to a delegated administrator. Also, when a product is created on a depot, the user and group identity of the creator is recorded in the product information.

If the product ACL contains an object_owner entry granting write permissions to the owner, then the product creator will automatically have rights to change or delete the product. Therefore, the depot can be more widely opened to insertion because users with insert permission can only copy in new products or delete their own products: you don’t have to worry about a user erroneously deleting some critical product that they shouldn’t control.

The rationale for this protection scheme is borrowed from a mechanism introduced in the BSD file system. With write permissions on a BSD directory, you may create a file in the directory. If the sticky mode bit is set on the directory, only the file owner, the directory owner, or superuser may remove or rename the file.

For example: In /tmp, owned by root, with “wide-open” write permission and the sticky bit set manually (i.e., mode 1777), anyone can create files that nobody else (except themselves and superuser) can remove. This makes /tmp a more secure place to store temporary work because someone else can’t delete your files there.

Installing or copying from an unregistered depot requires the user and the target agent’s host to have insert permission on the depot’s host. If this permission is denied to the target’s host, the depot’s daemon log will contain the message:

ERROR: Access denied to SD agent at host lucille on 
behalf of rob@lucille to start agent on unregistered 
depot "/users/rob/depot." No (i)nsert permission on 
host.
  07/23/01 15:51:06 MDT

This message indicates it is the agent at lucille that did not have insert permission on the depot’s host, not the user rob@lucille.

The remote host ACL must have two entries granting insert permission: one for the user, and one for the target host.

For example, for user rob to be allowed to install a product on target host lucille from an unregistered depot on source host desi, the command

swacl -l host @ desi

must show the minimum ACL entries

user:rob@lucille:-i-
 host:lucille:-i-

Rob could alternatively register the depot with the swreg command with only the first entry above before running swinstall or swcopy.

Host System ACLs

The host system is the highest level of protected object in SD-UX. A host ACL protects each host system, controlling permission to create depots and roots. The host ACL may grant the following permissions:

Table 9-7 Host ACL Permissions

`r (`read)	Permission to obtain host attributes, including a list of depots and roots on the host.
`w (`write)	Permission to change the host object.
`i (`insert)	Permission to create and register a new depot or root on the host.
`c (`control)	Permission to edit or change the ACL.
`t (`test)	Permission to test access to an object and list the ACL.

A sample host-system ACL grants depot and root source creation, source listing, and ACL administration to a user named rob and give open permission to list the depots and roots on the host, would be:

user:rob:r-ic-
any_other:r

Since any_other does not havet (test) permission, only rob can list this ACL, because he has c (control permission).

Root ACLs

Principals (users) identified in ACLs that are protecting roots are granted permission to manage installed products. The permissions associated with a root are:

Table 9-8 Root Permissions

`i`(insert)	Permission to install a new product.
`r`(read)	Permission to list the contents of the root.
`w`(write)	Permission to delete the root itself or the products in the root.
`c`(control)	Permission to edit or change the ACL.
`t (`test)	Permission to test access to an object and list the ACL.

A sample root ACL that grants a user named lois permission to read, write, and insert software and members of the group named swadm all possible permissions is:

user:lois:rwi-
group:swadm:crwit

When a root is created, it is automatically protected by a default ACL derived from its host. Use swacl to change the initial values of this ACL. For additional information, see “ACL Templates ”.

Depot ACLs

Principals identified in ACLs that are protecting depots are users who have been granted permission to manage the depot and to create new products. The permissions associated with a depot are:

Table 9-9 Depot Permissions

`i`(insert)	Permission to copy a new product into the depot.
`r (read)`	Permission to list the contents (products) of the depot source.
`w (write)`	Permission to delete the depot (if it is empty), and unregister itself (not the products in the depot).
`c (control)`	Permission to edit or change the ACL.
`t (test)`	Permission to test access to an object and list the ACL.

A sample depot ACL that grants its creator all permissions; user george permission to list and insert software products; members of group swadm permission to list and insert products, change the ACL and delete the depot itself; and everyone else permission to list the contents of the depot, would be:

object_owner:crwit
user:george:-r-i-
group:swadm:crwi-
any_other:-r-

When a depot source object is created, it is automatically protected by a default ACL derived from its host. Products inserted in that depot will automatically be protected by an ACL derived from the depot. This concept is discussed in the “ACL Templates ”.

Product ACLs

Product ACLs only apply to products on depots. Products on roots are protected by the root’s ACL. There are two classes of principals that are granted access rights to products:

Table 9-10 Product Principals

users	Granted various administrative permissions. This class includes groups and others, both local and remote.
hosts	Target systems (agent/daemons) granted read permissions to allow product installation.

Permissions on products are:

Table 9-11 Product Permissions

`w (`write)	Permission to users to change and delete the product and/or product information.
`r (`read)	Permission granted to target_hosts to read the source-depot product. (that is, grant permission to a remote system to install the protected product).
`c (`control)	Permission to edit or change the ACL.
`t (`test)	Permission to test access to an object.

A sample product ACL that grants user swadm and the creator of the product all permissions and allows open read permission (allowing free distribution to all systems) would be:

user:swadm:crw
object_owner:crw
any_other:-r-




	NOTE: When a product object is created, it is automatically protected by a default ACL from the depot/root source or, absent that, one from the host.

ACL Templates

There are two ACLs that are used to create the initial ACLs that protect newly created objects: product ACL templates (global_product_template or product_template) and container ACL templates (global_soc_template).

Figure 9-2 ACL Templates

When a product is put into a depot with swcopy or swpackage, SD-UX uses a product ACL template (provided by the depot that contains that product) to define the initial permissions of the new product’s ACL.

SD-UX uses the product ACL template of the host system (global_product_template) to initialize the product ACL template of the new depot and uses the container ACL template of the host system (global_soc_template) to initialize depot and root ACLs.

Thus, there are three ACLs on the host:

Host ACL
Attached to and controlling access to the host object itself.
Container ACL Template (global_soc_template)
Used to initialize the ACL protecting new depots and roots created on the host.
Product ACL Template (global_product_template)
The ACL that is used to initialize the product ACL template on depots that are created on the host.

There are also two ACLs on product depots:

The depot’s ACL that is used to determine permissions on the depot.
The depot’s product ACL template (product_template) that is used to initialize the ACLs protecting new products on the depot.

There is one ACL on the installation (root):

The root ACL that protects the root and products installed on it.

And finally, there is one ACL on the product:

The product’s ACL that is used to determine permissions on the product.

Every host must have an ACL protecting it and a pair of template ACLs (product and container) to provide initialization data for implicit depot and product ACLs. All three are created when SD-UX is installed on the host.

Default ACL Template Entries

The host system’s container ACL template dictates initial permissions on all depots and roots that are introduced on that host. The host also contains a master copy of a product ACL template, which is copied to each new depot.

A default set of host ACLs is provided at the time SD-UX is installed that can be altered by the SD-UX administrator. The contents of these host-system ACLs immediately after SD-UX installation are:

Host ACL

The host ACL below allows global (any_other) permission to list the depots and roots on the host:
object_owner:swadm:crwit any_other:-r---




	NOTE: Remember, the local superuser always has all permissions, even without an ACL entry.

Container ACL Template

The container ACL template below grants the owner or creator (object_owner) of a new depot or root permission to manage that new depot or root and to change its ACL. It also grants global permission (any_other) to list products in the new depot or root.
object_owner:crwit any_other:-r---

Product ACL Template

The product ACL template below grants permission to perform all operations on products installed on Depots on this host to the respective creator (i.e., owner), via the object_owner entry, of each product. It also grants permission to read (i.e., install) and test the product to any host (the any_other entry).
object_owner:crwit any_other:-r---
In addition to encompassing all hosts, the any_other entry also applies to all other users except, in this case, the product’s owner. In SD-UX however, product read permission has meaning only to host principals, and other possible product permissions never apply to hosts; therefore, the any_other entry may be overloaded with user and host permissions, if desired, without any danger of ambiguity. This overloading should be kept in mind when using the SD-UX to execute solutions.

These host ACL defaults provide a good starting point for control over the management functions of SD-UX while providing open access to read the software for installation on root targets.