Volume Access Control

When enabled, the volumes that are owned by a specific user are accessible only to that user or to trusted other users.

The first time you configure ACSLS for volume access control follow these steps:

Enable volume access control in ACSLS.
Associate a client application with a user name.
Define which other users may have access to the user's volumes.
Establish ownership of the volumes.

Enabling Volume Access Control

To enable volume access control in ACSLS:

Run the configuration utility, acsss_config.
The main menu displays.
Select Option 4 - Set Access Control Variables.
Each variable is listed one at a time, and its current setting is displayed.
Click Enter to accept the current or default setting.
Select [TRUE] and click Enter when the utility displays the message:
Access control is active for volumes
Select one of the following when the utility displays the message:
Default access for volumes [ACCESS/NOACCESS]
- Select [ACCESS] if your goal is to disallow access to specific users and allow access to all others.
  
  This requires specific users to be listed in a users.ALL.disallow file or a specific users.COMMAND.disallow file. See Defining other users that are allowed access to the user's volumes.
- Select [NOACCESS] if your goal is to allow access to specific users and disallow access to all others.
  
  This requires specific users to be listed in a users.ALL.allow file or a specific users.COMMAND.allow file. See Defining other users that are allowed access to the user's volumes.
  
  If you want to log instances where access to volumes is denied, select [TRUE] in response to that prompt.
  
  Whenever enabling or disabling volume access, you must restart ACSLS for the change to take effect.

Associating a Client Identity with a User Name

Not all client applications pass a user ID with its ACSLS request packets. In cases where the client is not identified by a user name, you can assign a user ID.

Go to the access_control configuration directory:
$ACS_HOME/data/external/access_control
Create a file by the name internet.addresses or copy theinternet.addresses.SAMPLE file.
In this file, create a record for each client. Each record contains at least two fields: the client IP address followed by a corresponding user name. You can include additional fields for comments.
Separate the fields with spaces or tabs, as shown in the following example:

192.0.2.1 ulyssis payroll department
You can create as many client-user associations as you have client applications.
- Where client applications pass the user name with the ACSLS request, the internet.addresses file authenticates the user name with the designated IP address and denies access where both fields do not agree with the values in the request packet. Where multiple clients are hosted from a common platform, the same IP address may be included multiple times in this file, and this address can be associated with as many user names as are rightly applied to that IP address.
- Where client applications do not pass the user name with the request, the internet.addresses file establishes a user name for that client. In this case, only one user name may be associated with any client I address.
Save any updates to the internet.addresses file:
- Run acsss_config.
- Select Option 6 - "Rebuild Access Control Information".
ACSLS dynamically recognizes the change.

or SNA and OSLAN clients that do not use TCP/IP, refer to the lu62.names or adi.names file in the access_control directory.

Defining other users that are allowed access to the user's volumes

To grant other users access to a users' owned volumes:

Create a file users.ALL.allow or users.ALL.disallow in the access_control directory.

You can copy the templates users.SAMPLE.allow or users.SAMPLE.disallow.
Add a record in the file for each owner, placing the owners' user ID at the left margin.
Specify affected users on the same line with each owner.
Separate the user names with spaces or tabs, as shown in the following example:
```
owner_john   user-Allie   user-andre 
```
User names listed in the users.allow and users.disallow files must be unique, without regard to case. The type case of characters in the user name is ignored.

Users who are not listed on the same line with the owner are given the default (ACCESS or NOACCESS) relationship to the owner's volumes.

Note:
You cannot have the same owner_ID and user_ID pair in both the users.COMMAND.allow and users.COMMAND.disallow files for the same command or ALL. You also cannot have the duplicate owner_ID and user_ID pair in the same users.COMMAND.allow and users.COMMAND.disallow files. This includes repeating the same user_ID on the same line.
If there are more allowed users for an owner than will fit on one line, the list of allowed users can be continued on subsequent lines. Each line must start with the owner ID.
Optionally, you can establish exceptions to the volume access policy you have defined.
Generally, users are allowed full access, or no access to volumes that are under access control. However, it is possible to allow users certain restricted access to other users' volumes.

For example, you can set a policy that allows any user to query volumes that are owned by a specific user, even though they may not mount or dismount those volumes. Exceptions can be applied to any of the commands that are affected by access control:

To configure volume access policy exceptions for certain commands:
- You must create a users.COMMAND.allow or users.COMMAND.disallow file (where COMMAND is replaced by the specific command you want to grant or restrict).
  
  The users.COMMAND.allow and users.COMMAND.disallow files must have a command component with the name specified exactly as listed below, with the name of the command in uppercase. Controlling access to other variants of commands (such as QUERY_VOLUME) is not supported.
```
DISMOUNT 
EJECT 
LOCK 
MOUNT (1) 
MOUNT_READONLY (2) 
QUERY 
REGISTER 
SET_CLEAN 
SET_SCRATCH 
UNLOCK 
```
  Notes:
  - MOUNT (1) - MOUNT policies also apply to mount scratch. Policies do not apply to mount readonly
  - MOUNT_READOLNY (2) - Policies for mount readonly are defined separately from mount.
  - The considerations above about no duplicate owner ID and allowed user ID pairs and continuing lists of allowed users on subsequent lines also apply to lists of disallowed users.
- For each owner, place the owner's name at the left margin, followed by the users for whom the policy applies.
Save any updates to the policies you define:
- Run acsss_config
- Select Option 6 - "Rebuild Access Control Information".
ACSLS dynamically recognizes the change.

Establishing Ownership of Your Volumes

Volume access control applies only to volumes that have explicit ownership. Unowned volumes in the library are accessible to any user. To explicitly set volume ownership use the cmd_proc interface:

ACSSA>set owner "daffy" volume V00100-V00199 
Set: owner set for volumes V00100-V00199 
Set: Set completed, Success.

You can remove ownership in a similar fashion by using an empty string:

ACSSA> set owner "" volume V00100-V00199 
Set: owner set for volumes V00100-V00199

This operation clears the ownership from all of the volumes in the range. For more information, see set owner.

Volume ownership can be set automatically by the watch_vols utility. For more information, see watch_vols.

Ownership policies

A policy for setting and removing ownership automatically can also be defined in ACSLS. For example, you can set a policy in which any scratch volume that is mounted becomes owned by the user who mounted it. Thereafter, the volume is owned by that user. The same policy could be enhanced to remove ownership whenever the volume is returned to scratch status. A policy could be written such that all entered volumes are assigned to a default user, or to the user who requested the enter, or if the volume was previously owned, to its prior owner. Considerable flexibility is offered with this feature.

Ownership policies are defined in the ownership.assignments file which resides in the access_control directory. You can set a policy in this file to assign or to un-assign ownership automatically with each enter or automatic enter, set scratch, or mount scratch operation. The ownership.assignments file allows you to define a default owner. Whenever a volume encounters any of these operations, its ownership can be assigned to:

Owner_default (the default owner)
Same (the previous owner)
Requestor (the user issuing the current request)
Unowned (retract ownership from the volume)

Note:
Instructions for defining ownership policies are described in detail in the ownership.assignments file. This file includes a complete list of commands that can be used to set volume ownership.
Save any updates to the policies you define:
- Run acsss_config
- Select Option 6 - Rebuild Access Control Information.
ACSLS dynamically recognizes the change.

Verifying Ownership

To verify ownership you can run volrpt using the owner_id.volrpt template.

cd ~acsss/data/external/volrpt 
volrpt -f owner_id.volrpt

This produces a display of all the volumes in the library listed with their associated owner.

Volume Access Summary

The following commands are supported by Volume Access Control:

dismount* 
display 
eject 
enter 
lock 
set_clean 
set_scratch 
mount 
query_mount 
query_scratch 
query_volume 
unlock

Access control does not apply to dismount force since the force option instructs StorageTek ACSLS to ignore the volume ID and to dismount to volume unconditionally, unless it is in STATUS_DRIVE_RESERVED state.

The following table summarizes the contexts that apply when volume access control is enabled.

Table 6-1 Volume Access is Enabled - ACCESS

Default access for volumes is ACCESS	Access Allowed	Access Denied
Access is through `cmd_proc`	X	-
The specified volume is unowned	X	-
The user is the owner of the volume	X	-
The user is associated with the owner in `users.ALL.disallow`	-	X
If the user is not associated with the owner in `users.ALL.disallow`	X	-

Table 6-2 Volume Access is Enabled - NOACCESS

Default access for volumes is NOACCESS	Access Allowed	Access Denied
Access is through `cmd_proc`	X	-
The specified volume is unowned	X	-
The user is the owner of the volume	X	-
The user is associated with the owner in `users.ALL.allow`	X	-
If the user is not associated with the owner in `users.ALL.allow`	-	X