6 Access Control

Access Control provides the following:

  • Volume Access Control allows volumes to be assigned to one client application. Other clients can be allowed to access the client's volumes.

  • Command Access Control allows administrators to assign specific ACSLS commands to specific clients.

Both volume access control and command access control apply to users of client applications who submit requests through the ACSAPI.

Access control does not restrict access by administrative users who submit library requests using cmd_proc or the ACSLS GUI.

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:

  1. Enable volume access control in ACSLS.

  2. Associate a client application with a user name.

  3. Define which other users may have access to the user's volumes.

  4. Establish ownership of the volumes.

Enabling Volume Access Control

To enable volume access control in ACSLS:

  1. Run the configuration utility, acsss_config.

    The main menu displays.

  2. Select Option 4 - Set Access Control Variables.

    Each variable is listed one at a time, and its current setting is displayed.

  3. Click Enter to accept the current or default setting.

  4. Select [TRUE] and click Enter when the utility displays the message Access control is active for volumes.

  5. 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.

  1. Go to the access_control configuration directory:

    $ACS_HOME/data/external/access_control.

  2. Create a file by the name internet.addresses or copy theinternet.addresses.SAMPLE file.

  3. 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.

  4. Save any updates to the internet.addresses file:

    • Run acsss_config.

    • Select Option 6 - "Rebuild Access Control Information".

    ACSLS dynamically recognizes the change.

    For 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:

  1. 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.

  2. Add a record in the file for each owner, placing the owners' user ID at the left margin.

  3. Specify affected users on the same line with each owner.

  4. 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.

  5. 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.

  6. 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, refer to "set owner".

Volume ownership can be set automatically by the watch_vols utility. For more information, refer to"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

Command Access Control

Command access control allows an ACSLS administrator to restrict certain classes of commands to specific client applications or specific users across the network. Controlled access applies only to user commands that are submitted through the ACSAPI and it does not apply to local users who submit commands using cmd_proc.

The process to configure ACSLS for command access control involves three steps.

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

  1. Enable command access control in ACSLS.

  2. Associate a client identity with a user name.

  3. Define what commands are available to which users.

Enabling Command Access Control

To enable command access control in ACSLS,

  1. Run the configuration utility, acsss_config.

    The main menu displays.

  2. Select Option 4 - Set Access Control Variables.

    Each variable is listed, one at a time, and its current setting is displayed.

  3. Click Enter to accept the current or default setting.

  4. Select TRUE and click Enter when the utility displays the message Access control is active for commands.

  5. When the message "Default access for commands" is displayed:

    • Select ACCESS if you want to allow all users access to all commands.

      To block specific users from issuing commands, they must be listed in a command.ALL.disallow file or a specific command.XXX.disallow file, where:

      XXX is the command for which access control is intended

    • Select [NOACCESS] if you want to deny user access to commands.

      To allow specific users to issue commands, they must be listed in a command.ALL.allow file or a specific command.XXX.allow file.

      Note:

      If you want to log instances where access to commands is denied, enter "TRUE" in response to that prompt.

      Note:

      Whenever enabling or disabling command access, you must restart ACSLS for the change to take effect.

Associating a client identity with a user name

Refer to the procedures under "Associating a client identity with a user name".

Defining What Commands are Available to Which Users

This process depends upon the default behavior you have selected when you enabled command access control. You must create a policy file in the $ACS_HOME/data/external/access_control directory.

  • If the default behavior you defined above is [NOACCESS], you must create a command.ALL.allow file that contains the user ID of each client that is to have access to all ACSLS commands. Each user ID should be listed on a separate line in the file.

    If you want to grant only specific commands to specific users, you must create command.XXX.allow files for each command the users are allowed to execute. For example, to grant permission for specific users to enter volumes into the library, you would create a file with the name command.ENTER.allow and list the ID of each qualified 'enter' user on a separate line in the file.

  • If the default behavior you defined above is [ACCESS], you must create a command.ALL disallow file that contains the user ID of each client that is not to have access to all ACSLS commands. Each user ID should be listed on a separate line in the file.

    Note:

    You cannot have the same user_ID in both the command.XXX.allow and command.XXX.disallow command.XXX files for the same command or ALL.

Command Names for Command Access Control allow and disallow Files

The command.XXX.allow and command.XXX.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.

AUDIT 
CANCEL 
CHECK_REGISTRATION 
CLEAR_LOCK 
DEFINE_POOL 
DELETE_POOL 
DISMOUNTDISMOUNT_FORCE 
DISPLAY 
EJECT 
ENTER      (1) 
IDLE 
LOCK 
MOUNT      (2) 
QUERY 
QUERY_LOCK 
REGISTER 
SET_CAP 
SET_CLEAN 
SET_OWNER 
SET_SCRATCH 
START 
UNLOCK 
UNREGISTER 
VARY

Note:

ENTER (1) - Policies apply to virtual enter and manual enter, but not for automatic enter. MOUNT (2) - Policies also apply to mount scratch and mount readonly.

Use the following table as a quick reference for determining when command access is allowed.

Table 6-3 Command Access is Enabled - NOACCESS

Default Access for Commands is NOACCESS Access
Allowed		 Access
Denied

The request is entered from cmd_proc

X

  

The user_ID is listed in command.COMMAND.allow

X

  

The user_ID is listed in command.ALL.allow

X

  

- - All other conditions - -

  

X

Table 6-4 Command Access is Enabled - ACCESS

Default Access for Commands is ACCESS Access
Allowed		 Access
Denied

The request is entered from cmd_proc

X

  

The user_ID is listed in command.COMMAND.disallow

  

X

The user_ID is listed in command.ALL.disallow

  

X

- - All other conditions - -

X

  

  • Save any updates to the policies you define:

    • Run acsss_config

    • Select Option 6 - "Rebuild Access Control Information".

    ACSLS dynamically recognizes the change.

Logging Access Control Messages

You can set a policy to log all transactions that failed because the user was denied access. The message displays the user name and the command that was attempted.

To enable access control logging:

  1. Run acsss_config and select Option 4 - "Set Access Control Variables"

  2. Change [FALSE] to [TRUE] at the following prompt: "Messages will be logged when access to commands or volumes is denied.

  3. Select Option 6 - "Rebuild access control information."

ACSLS recognizes the change and begins logging each time a command request was denied.