IBM Books

Administration Guide


Managing authorization information

This section includes the following topics for managing authorization information:

Managing access by group membership

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

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

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:

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:

  1. ACL files for multiple instances of the Sysctl service can be managed consistently and efficiently across the entire SP system in one transaction.
  2. 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:

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 ]