Administration Guide

Managing authorization information

This section includes the following topics for managing authorization information:

Managing access by group membership.
Managing access using ACL files.

Managing access by group membership

This section includes the following topics for authorizing access by group membership:

Authorizations assigned to groups.
Adding, deleting, and displaying group members.

Authorizations assigned to groups for DCE

Table 2 lists the default DCE group names and the SP trusted services that use them.

Table 2. DCE group names for use of SP trusted services

DCE default group name	Purpose of group
haem-users	Authorizes use of Event Management.*
hm-admin	Authorizes administrative tasks used to manage the SP Hardware Monitor.
hm-control	Authorizes all SP Hardware Monitor tasks except administration and includes hm-monitor authorization.
hm-monitor	Authorizes monitoring of SP hardware. This is read-only access to the SP Hardware Monitor.
sdr-admin	Authorizes SDR tasks on partitioned classes.*
sdr-write	Authorizes all SDR updates to existing partitioned classes, but not the addition or deletion of classes or other administrative tasks.*
sdr-system-class-admin	Authorizes all SDR tasks on global system classes
sdr-system-class-write	Authorizes SDR updates to existing system classes, but not the addition or deletion of system classes or other administrative tasks.
switchtbld-clean	Authorizes cleanup, the unloading, of switch tables.
switchtbld-load	Authorizes loading of switch tables.
switchtbld-status	Authorizes querying the status of loaded switch tables.
sysctl-cwsroot	Authorizes use of certain switch management commands by non-root users of SP Perspectives. Sysctl creates a group entry for it in the etc/sysctl.rootcmds.acl DCE ACL file.
sysctl-default	Sysctl creates a group entry for it in any ACL added by customization (not supported by IBM).
sysctl-logmgt	Authorizes use of log management commands by non-root users. Sysctl creates a group entry for it in the etc/logmgt.acl DCE ACL file.
sysctl-master	Authorizes full access to all Sysctl facilities including Sysctl administration. Sysctl creates a group entry for it in the etc/sysctl.acl DCE ACL file.
sysctl-mmcmd	Authorizes access to GPFS commands. Sysctl creates a group entry for it in the etc/sysctl.mmcmd.acl DCE ACL file.
sysctl-pman	Authorizes access to Problem Management commands. Sysctl creates a group entry for it in the etc/sysctl.pman.acl DCE ACL file.
sysctl-vsd	Authorizes access to Virtual Shared Disk commands. Sysctl creates a group entry for it in the etc/sysctl.vsd.acl DCE ACL file.
* To allow separate groups of users to access the resources of each system partition, this group can by partitioned during installation and configuration by using the spsec_overrides file.

Authorizations assigned to groups for AIX

AIX group names related to PSSP are shutdown, cshut, and hagsuser. Use the shutdown or cshut groups to authorize users to run the cstartup and cshutdown commands. Use the hagsuser group to authorize non-root users to use Group Services.

Adding, deleting, and displaying group members for DCE

See "Maintaining Membership Lists" and "Project Lists" in the book IBM DCE Version 3.1 for AIX: Administration Guide-Core Components.

Adding, deleting, and displaying group members for AIX

See "Users and Groups" in the book AIX Version 4.3 System Management Concepts: Operating Systems and Devices and AIX Version 4.3 System Management Guide: Operating Systems and Devices.

Managing access using ACL files

This section includes the following topics:

AIX Remote Command Authorization Files
Managing DCE ACLs for SP Trusted Services
Managing Kerberos V4 ACLs for SP Trusted Services

AIX remote command authorization files

The methods of authorizing users for access on a target system vary according to the authentication methods used. Generally there is one type of authorization file for each authentication method in the SP system. |However, when you are running with a secure remote command process |enabled, you can choose to not have an authorization file for AIX remote |commands. The control workstation and the nodes which are configured for an authorization method maintain their own copy of that method's authorization file. |For all methods except a secure remote command process, access is based on the contents of a file in the target user's home directory:

DCE - the .k5login file contains a list of authorized Kerberos V5 principal names.
Kerberos V4 - the .klogin file contains a list of authorized Kerberos V4 principal names. Any nodes running a release earlier than PSSP 3.2 require Kerberos V4.
Standard AIX - the .rhosts file contains a list of authorized source host names and user names.

See AIX remote command authorization files for more information.

Managing DCE ACLs for SP trusted services

Generally, to manage DCE ACL entries you can use the DCE dcecp acl command and related SMIT panels. PSSP 3.2 provides the spacl command and the spauth_spacl SMIT fastpath to simplify managing ACLs specifically for the Hardware Monitor and Sysctl SP trusted services.

The SP ACL management component of PSSP offers the following advantages:

ACL files for multiple instances of the Sysctl service can be managed consistently and efficiently across the entire SP system in one transaction.
When using SMIT, you can select the service and the objects for which the action is to be performed, which means you avoid a lot of manual data entry.

You can perform the following actions:

List SP ACL entries.

Add SP ACL entries.

Change SP ACL entries.

Remove SP ACL entries.

Show permissions defined for a service.

Check your permissions on an object.

These actions operate by default on all instances of an object's ACL in the default SP system partition. When you do not want to act on all instances you can define a subset of instances in any of the following ways:

Selecting an SP system partition.
Selecting a predefined node group.
Entering a comma-delimited list of node numbers or the name of a file that contains such a list.
Setting a node range with starting frame number, starting slot number, and node count.

Understanding the information used by SP ACL management

You ought to be familiar with the naming convention for DCE entities such as service principals, access groups, and CDS paths, which are used by SP security services in PSSP. (See DCE entities used by SP security services.)

Note:: If you used the spsec_overrides file to change the name for the ssp/sysctl or the ssp/hardmon service or to change the name of access groups, remember to use the changed names as input to the spacl command. When you use SMIT, the selection lists contain the changed names.

Object names are given by the SP trusted service by which they are created and controlled. The spauth_spacl SMIT interface shows a list of the objects on which you can operate. You can also use the spacl command to list them.

Some actions ask you to supply an ACL entry in the DCE standard form:

type:key:permissions

For information on how to specify type and key, see the book IBM DCE Version 3.1 for AIX: Administration Guide-Core Components. For information on permissions for the Hardware Monitor, see Understanding authorization for hardware objects. For information on Sysctl permissions, see DCE ACLs.

Types of DCE ACL entries

Sysctl creates only group entries in its DCE ACLs. However, the following entry types are supported:

mask_obj

unauthenticated

user

group

other_obj

any_other

foreign_user

foreign_group

foreign_other

The following entry types are allowed by Sysctl and DCE, but are meaningless, because Sysctl does not use delegated credentials:

user_delegate

group_delegate

other_obj_delegate

any_other_delegate

foreign_user_delegate

foreign_group_delegate

The following entry types are not allowed in Sysctl ACLs by DCE:

user_obj

group_obj

user_obj_delegate

group_obj_delegate

Querying Access Permissions Defined by a Service

SP trusted service objects are protected by different sets of access permissions as defined by the service that owns them. You can list the permissions defined for objects relative to the service. You can use the SMIT fastpath spacl_perms to get directly to that part of the spauth_spacl interface, or you can use the spacl command.

For information on the permissions used by the hardware monitor, see Understanding authorization for hardware objects. For information on Sysctl permissions, see Permissions in Sysctl ACLs.

For example, to see the permissions defined for Hardware Monitor objects, run the following command:

spacl -a permissions -s ssp/hardmon

The output is a list of single lower case letters and their meanings.

Checking your access permissions to objects

Before you change SP ACL entries, you might want to check if you have permission to make the changes. For example, to see if you can change the ACL of the Hardware Monitor object frame1/slot1, run the command:

spacl -a check -s ssp/hardmon -o frame1/slot1

The output is a list of the access permissions you have for that object.

Understanding the access permissions needed to perform SP ACL management

Although the set of access permissions are defined by each service, all sets must contain the following:

c - permission to change the ACL of the object.

t - permission to query your own access permissions to the object.

In order to successfully run any of these SMIT interfaces or commands, there must be an ACL entry associated with the object (frame1/slot1 in the previous examples) that contains your principal name or a group in which you are a member where your effective permissions include t.

Examples of listing ACL entries

To list ACL entries using SMIT:

TYPE: smit spacl_list
SELECT: the SP trusted service such as ssp/hardmon
SELECT: the name of the object such as system
PRESS: OK

To list ACL entries using the CLI, run a command similar to the following which lists the entries for the system object:

spacl -a show -s ssp/hardmon -o system

Examples of adding ACL entries

To add ACL entries using SMIT:

TYPE: smit spacl_add
SELECT: the SP trusted service such as ssp/hardmon
SELECT: the name of the object such as hardmon
TYPE: the ACL entry such as user:joe
TYPE: the permissions such as at
PRESS: OK

To add ACL entries using the CLI, run a command similar to the following which adds an entry for user joe to the hardmon object:

spacl -a add -s ssp/hardmon -o hardmon -e user:joe -p at

Examples of changing ACL entries

To change ACL entries using SMIT:

TYPE: smit spacl_change
SELECT: the SP trusted service such as ssp/hardmon
SELECT: the name of the object such as hardmon
TYPE: the ACL entry such as group:hm-admin
TYPE: the permissions such as at
PRESS: OK

To change ACL entries using the CLI, run a command similar to the following which changes the permissions in the hm-admin group entry for the hardmon object in the Hardware Monitor:

spacl -a change -s ssp/hardmon -o hardmon -e group:hm-admin -p at

Examples of removing ACL entries

To remove ACL entries using SMIT:

TYPE: smit spacl_remove
SELECT: the SP trusted service such as ssp/hardmon
SELECT: the name of the object such as hardmon
TYPE: the ACL entry such as user:joe
PRESS: OK

To change ACL entries using the CLI, run a command similar to the following which removes an entry for the user joe from the hardmon object in the Hardware Monitor:

spacl -a remove -s ssp/hardmon -o hardmon -e user:joe

Examples of showing all ACL permissions

To show all ACL permissions using SMIT:

TYPE: smit spacl_perms
SELECT: the SP trusted service such as ssp/hardmon
SELECT: the name of the object such as system
PRESS: OK

To show all ACL permissions using the CLI, run a command similar to the following which shows all the permissions for the system object in the Hardware Monitor:

spacl -a perm -s ssp/hardmon -o system

Examples of checking your ACL permissions

To check your ACL permissions using SMIT:

TYPE: smit spacl_check
SELECT: the SP trusted service such as ssp/hardmon
SELECT: the name of the object such as frame1/slot1
PRESS: OK

To check your ACL permissions using the CLI, run a command similar to the following which shows your permissions for the frame1/slot1 object in the Hardware Monitor:

spacl -a check -s ssp/hardmon -o frame1/slot1

Managing Kerberos V4 ACLs for SP trusted services

There is no single facility that provides an ACL management interface for Hardware Monitor and Sysctl ACL files.

A single ACL file named hmacls is used for authorization of Kerberos V4 principals by the Hardware Monitor. Its entries contain the object name in addition to the principal name and permissions. You can change this ASCII file using the text editor of your choice. For more information about managing Hardware Monitor ACL files, see Step 1: Authorize users for the SP System Monitor.

Sysctl ACLs are also ASCII files that can be edited directly. The path name for them, relative to the root directory (/), is the same as the DCE object name used to reference the DCE Sysctl ACLs. Sysctl provides built-in ACL management procedures that you can use to create, change, list, and remove these files. Because Sysctl provides parallel access to multiple Sysctl servers, you can update multiple instances on a single request, as with the SP ACL management facility for DCE ACLs. For more information on Sysctl ACL management, see Sysctl files. For information on the format of Sysctl ACL files, see "sysctl_acl File" in the book PSSP: Command and Technical Reference.

[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]