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.
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.
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.
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.
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 o
r 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 u
sers.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 sameowner_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.
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" .
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 theownership.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.
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 |
X |
|
The specified volume is unowned |
X |
|
The user is the owner of the volume |
X |
|
The user is associated with the owner |
X |
|
If the user is not associated with the owner |
X |
Table 6-2 Volume Access is Enabled - NOACCESS
Default access for volumes is NOACCESS | Access Allowed |
Access Denied |
---|---|---|
Access is through |
X |
|
The specified volume is unowned |
X |
|
The user is the owner of the volume |
X |
|
The user is associated with the owner |
X |
|
If the user is not associated with the owner |
X |
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:
Enable command access control in ACSLS.
Associate a client identity with a user name.
Define what commands are available to which users.
To enable command 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 commands
.
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.Refer to the procedures under "Associating a client identity with a user name".
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 thecommand
.XXX
.allow
and command
.XXX
.disallow
command.XXX
files for the same command or ALL.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 tomount 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 |
X |
|
The user_ID is listed in |
X |
|
The user_ID is listed in |
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 |
X |
|
The user_ID is listed in |
X |
|
The user_ID is listed in |
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.
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:
Run acsss_config
and select Option 4 - "Set Access Control Variables"
Change [FALSE] to [TRUE] at the following prompt: "Messages will be logged when access to commands or volumes is denied.
Select Option 6 - "Rebuild access control information."
ACSLS recognizes the change and begins logging each time a command request was denied.