IBM Books

Administration Guide



A Sysctl server provides remote access to a set of commands for authenticated and authorized clients. Since the Sysctl server is running with UID 0, these commands are executed with root privilege. These commands are embedded in an interpreter within the server. Sysctl uses the Tool Command Language (Tcl) as the foundation for its built-in command interpreter. The commands are of the following types:

The Tcl interpreter that Sysctl uses is built from base Tcl and Extended Tcl. Refer to the ssp.public.README file for more information on Tcl as supplied with the SP.

Using an embedded language, particularly Tcl, provides the following advantages:


The management tools used to administer a large site need to be secure to prevent outside intrusion and to prevent accidental disasters, such as inadvertently deleting critical data.

Sysctl has the following security components:

Access control lists

An access control list (ACL) is a text file that can be used to grant authority to particular users to issue particular commands. Sysctl provides ACL-based authorization. See Sysctl files for more information.

Client authentication

The security services supported on the SP system provide trusted third party authentication of users. When a client issues a Sysctl command, client credentials are sent along with the command. The server uses that information to identify and authenticate the identity of the client.

Identification and authentication

Identification and authentication are procedures that a client and server use to verify their identities to each other. The objective is to provide an identity that the server can use for authorization. The way that identification and authentication take place is determined by the security policy established by your organization and implemented by the SP system and security administrators, as well as by the actions taken or not taken by an individual user. SP systems running PSSP 3.2 can be configured to support any of the following combinations of authentication methods for SP trusted services:

dce and compat

When one or both authentication methods is used for SP trusted services, as an authorized administrator, you must create principals in the authentication database to represent the clients. For the purpose of authentication, a client command uses the principal name of the user who is running it. Servers use service principal names that are predefined during system configuration. To establish how users obtain credentials so they can submit Sysctl requests as authenticated clients, do the following:

A user of the Sysctl facility can submit requests for remote execution as an unauthenticated AIX user or as an authenticated principal. The Sysctl client command obtains and forwards to the target server, the AIX user name that submitted the command as an unauthenticated identity, plus whatever authentication credentials are available. The client might have a DCE identity, a Kerberos V4 identity, both, or only the unauthenticated AIX identity. The server then tries to establish an authenticated identity for the client. Depending on which authentication methods are enabled and the availability of valid credentials, the server first tries a DCE principal, then a Kerberos V4 principal, and finally the AIX user name. When authentication succeeds using DCE, the server does not use other credentials submitted by the client. Authentication of the client by the server might fail because the credentials are invalid, the credentials are expired, or the server host is not configured to support any of the authentication methods enabled for the SP trusted services.

Messages reporting authentication errors are always suppressed if the client request is eventually successfully authorized because authorization did not require any of the unavailable forms of identity. When authorization does fail, it means that none of the identities established for the client are allowed to perform the requested task: neither DCE principal, Kerberos V4 principal, nor unauthenticated AIX user name. Following an authorization failure, all authentication failures are reported to the user, if any had occurred.

However do not infer, without investigating further, that a reported authentication failure was actually the reason for a denial of access. Denial of access can be caused by things other than authentication failures, such as the following:

Using Sysctl with mixed authentication environments

Given the flexibility in configuring security services on the SP system, the possibility that you might install and configure the SP security services client facilities on independent workstations, and the support for coexistence and interoperability of PSSP 3.2 with earlier versions, your SP system can have a complex security environment with multiple hosts configured differently. Though Kerberos V4 is now optional, unless you have a brand new SP system using PSSP 3.2 with only DCE authentication, Kerberos V4 must be configured in order for authentication to succeed. When the compatibility authentication method is in use on the system, but DCE is not, users must have Kerberos V4 credentials to use Sysctl facilities that require an authenticated identity. This is also true when any node is running with a PSSP release earlier than PSSP 3.2.

When all hosts are running PSSP 3.2, you do not have to configure and use any authentication methods for SP trusted services if the security policy of your organization allows access by unauthenticated clients. Where clients are allowed to be unauthenticated anonymous users, users can access Sysctl servers without regard to the security configuration. When used in this fashion, Sysctl provides no protection from unlimited access to root privileges on the server system. Avoid that mode of operation except, for example during initial installation, when all hosts are physically isolated from the network and access to the system is limited to authorized administrators.


When a user submits a Sysctl request, the process establishes the identity of the client, then that identity is used to determine whether the client has permission to do what is requested. The client can have any of the following forms of identity for authorization:

  1. An authenticated DCE principal.
  2. An authenticated Kerberos V4 principal.
  3. An unauthenticated AIX user name. 2

After the identity is established, the server uses the following authorization steps by default:

  1. The svcconnect callback is executed to apply a global level of access control to all requests.
  2. The request is passed to the Tcl interpreter which in turn executes the authorization callbacks for each procedure and variable referenced directly by the client request.

Unless you have reconfigured Sysctl without an svcconnect procedure, each request must be authorized by that procedure before proceeding to the second step. The default svcconnect policy is to allow requests only from authenticated clients when any authentication method for SP trusted services is used on the server host, and to allow all requests on hosts with no authentication method in use for SP trusted services. See the svcconnect Sysctl procedure for information on overriding the default policy.

After a request passes the first authorization step, access rights are determined by how access control is defined for individual Sysctl resources on your SP system. Sysctl supports multiple authorization methods. The most widely used and most flexible is based on access control lists. Each Sysctl procedure and read-only variable is associated at server configuration time with a Tcl procedure called an authorization callback. Basically, it is a procedure that Sysctl invokes immediately before accessing the object it protects, to determine whether to allow that access. It can use the identity of the client and server state information stored in predefined Tcl variables to make its decision. Apart from the predefined callbacks, Sysctl allows the author of a Sysctl procedure to provide a unique callback based on arbitrarily defined factors.

Built-in authorization callbacks

IBM provides and uses four predefined authorization callback procedures. You can also use them as they are, change them, or write others. The predefined callback procedures are the following:

A procedure that always returns a successful result. This allows access by any user: authenticated or not.

A procedure that does not allow access by a client. It is used to protect from direct access by the client, a procedure or variable that is used internally by already-defined procedures.

A procedure that returns a successful result if the client was authenticated, regardless of the method used. This allows access by any user with valid credentials, provided the server is configured to support the authentication method in use for SP trusted services to obtain those credentials.

A procedure that checks whether an access control list authorizes client access.

When the ACL callback is used to authorize a DCE principal, the name of the ACL in the callback specification is the name of a DCE object known to the DCE ACL management functions in the Sysctl server. When Sysctl is configured, each ACL object referenced by authorization callbacks is created by the server, if it did not previously exist. Each object has an owner that has control access (c permission) which grants the right to modify the ACL. The default owner for ACL objects is the spsec-admin group. This group is defined when PSSP is configured in the DCE cell, with the DCE cell administrator as its only member. The cell administrator must add other members to the group, as required by local security policy.

Members of the spsec-admin group use the DCE dcecp command to create, change, remove, and list ACL entries. The dcecp command requires references to objects to be fully qualified CDS names, consisting of the cell name (or the string /.: to denote the local cell), the CDS directory path for the RPC entry for the server, and the residual object name. For Sysctl, the CDS path to the Sysctl server on DCE host DCEhostname is /.:/subsys/ssp/DCEhostname/sysctl. The object name appended to the CDS path is the name in the ACL callback specification. For the permissions related to Sysctl objects, see Permissions in Sysctl ACLs.

To add an entry for DCE principal sarah to the problem management ACL on the node whose DCE hostname is node8, for example, an authorized administrator would execute the following dcecp subcommand:

acl modify /.:/subsys/ssp/node8/sysctl/etc/sysctl.pman.acl \
-entry -add user:sarah:at

When an ACL callback is used to authorize a request by a client other than a DCE principal, the name of the ACL is used as the fully qualified path name of an ASCII format file in which you have created ACL entries. If the callback is {ACL} with no path name, the default file defined by the $ACL variable is used. You create ACL entries in these files using built-in Sysctl procedures or an editor of your choice. Since the authorization callback for the acladd command is {ACL}, the entry in the default ACL file cannot be added using acladd, unless the user is authorized using DCE (such as by being a member of the sysctl-master DCE group).

When the server is running with both DCE and compatibility authentication methods active, it is only necessary to be authorized by either DCE or Kerberos V4 authentication. To avoid confusion, you might want to keep the authorization information in the DCE ACLs and groups consistent with information in the Kerberos V4 Sysctl ACL files. For example, to add an entry for Kerberos V4 principal sarah to the problem management ACL on all hosts listed in the /tmp/sphosts file, you might use the following command:

sysctl -c /tmp/sphosts acladd -f /etc/sysctl.pman.acl -p sarah

To use the acladd command, you would have to be authorized for global Sysctl access by an entry in the /etc/sysctl.acl file. Another way is to edit the files directly, but you would have to log in as root on each host to do it.

Using authorization callbacks

ACLs provide the most flexibility in implementing your access controls. The ways to authorize a client request differ depending on the form of identity established at the server. Note that a given client can have different identities for the same request on different target servers, since the identity is determined in part by the capabilities of the server.

A client authenticated using DCE can be granted access by the following:

A client authenticated using Kerberos V4 can be granted access by the following:

An unauthenticated client can be granted access by the following:

Bypassing authorization callbacks

There is an entry defined in the Sysctl ACL file that allows access to all unauthenticated users. This applies to requests from clients who have no Kerberos V4 or DCE credentials as well as to requests submitted using the command line option to bypass authentication.

In some situations, the server bypasses the authorization callbacks. Authorization callbacks are bypassed while the server does the following:

Sysctl executables

The executables are:

Sysctl daemon (sysctld)

The Sysctl server daemon, sysctld, processes all Sysctl client requests for the node on which it runs. There is a sysctld daemon running on each node of the SP system, as well as on the control workstation. The sysctld daemon runs as root and executes Tcl procedures for authenticated and authorized clients who may be local or remote users. See the sysctld man page for more information.

Client (sysctl)

The Sysctl client shell program, sysctl, offers a command line interface for communicating with sysctld. Together, sysctl and sysctld provide monitoring and execution abilities needed to remotely manage SP nodes. sysctl connects to a remote node's sysctld using TCP/IP, passes keywords and commands to the server, and writes any output returned to stdout and stderr. See the sysctl man page for more information.

Sysctl files

The Sysctl server files include the following:

Using the default Sysctl server configuration file

A configuration file is provided when Sysctl is installed on the control workstation and on each SP node. The default path name for this file is /etc/sysctl.conf. The configuration file modifies the state of the server by executing one or more configuration commands. The configuration commands create read-only variables, register procedures, include other configuration files, and create classes of commands.

Customizing the Sysctl server configuration file

You can customize Sysctl servers by manipulating this configuration file. Initial configuration takes place each time the sysctld daemon is started on an SP node or control workstation. When the PSSP software is installed, a script creates the sysctld subsystem under SRC control and adds an entry to the inittab to start it at boot time. When started, the daemon sets up its Tcl interpreter tables to contain the built-in procedures supplied with the product. Then it executes the /etc/sysctl.conf file, which is a Tcl script that invokes Sysctl procedures to create additional Sysctl objects (procedures, variables, and classes) that are provided for managing the SP system.

You can tailor the configuration file after initial installation to make your own additions or changes to the base Sysctl facilities. You can insert Sysctl and basic Tcl procedures that create new objects or change existing objects. You might prefer to create a separate customization script and add it to the default configuration file with an include procedure that names the new script. That method is used by the log management component of PSSP to add its Sysctl configuration information to the server.

You can use the create proc built-in procedure to add new procedures and the setauth built-in procedure to change the authorization callbacks assigned to already configured procedures. Authorization callbacks are bypassed during configuration, allowing any built-in Sysctl procedures to be invoked from within configuration scripts. For security, only root should have write authority to Sysctl configuration files, including any that you create.

When you assign an authorization callback procedure, the server does not check to see whether it exists. The following messages generated using the security auditing option show successful setting of a nonexistent callback:

Sep 10 10:30:55 AUDIT[cmd]: Creating procedure xxtest, callBack = {NoAuth}
Sep 10 10:30:55 AUDIT[sec]: Setting callback for command "xxtest" => {NoAuth}

When you try to use the procedure or variable protected by a nonexistent callback, however, the error will simply be reported as an authorization failure. If you run with security auditing turned on, messages like the following should be recorded in the server's log file:

Sep 10 10:31:17 <37d91620> AUDIT[tcl]: Evaluating: xxtest
Sep 10 10:31:17 <37d91620> AUDIT[sec]: Checking object authorization
                callback for command "xxtest": NoAuth
Sep 10 10:31:17 <37d91620> AUDIT[sec]: interp>result from object
                callback {NoAuth} = "Not a valid command name: "NoAuth"", retCode = 1
Sep 10 10:31:17 <37d91620> AUDIT[sec]: Authorization denied for command "xxtest"

See Sysctl installation and configuration information, the sysctld man page, and the sysctl.conf man page for more information about configuring your system for Sysctl.

ACL files provided for Sysctl

The following ACL files that Sysctl uses are provided:


The ACLs that Sysctl uses to authorize requests by authenticated DCE principals are not individual files that you manage directly, but data maintained by DCE and the Sysctl server in a database. There is an SP ACL management component of PSSP. You can manipulate the entries in the ACLs by using the SP ACL management or by using the standard DCE ACL management tools such as the dcecp command. Your interface to SP ACL management includes the spacl command and the spauth_spacl SMIT fastpath. See Managing DCE ACLs for SP trusted services.

If you use the DCE commands you must refer to the ACL using a fully-qualified CDS path of the server with the ACL name, as specified in the callback, appended to it. See the description of the ACL callback in Built-in authorization callbacks for details. Because DCE ACLs are managed by the server that owns them in cooperation with DCE, sysctld must be running in order to issue dcecp subcommands that reference Sysctl ACLs.

Permissions in Sysctl ACLs

DCE requires that all ACLs have at least one entry that grants control (c) permission: the authority to manage the ACL. All ACLs used by Sysctl are created with an initial entry that grants control authority to the spsec-admin DCE group. The group and initial members are established when the PSSP software is installed and configured. Unless the name has been locally overridden, the DCE cell_admin user principal is a member by default. Though you can create additional ACL entries granting control permission, the easiest and preferred method is to add members to the spsec-admin DCE group.

All other entries use only three permissions:

Grants access to all Sysctl procedures and variables protected by the ACL.

Allows a user to issue the acl check subcommand of dcecp.

Used to deny access.

ACLs used by Sysctl with DCE

Sysctl uses the following ACLs when the DCE authentication method is in use:

Sysctl creates only group entries in its DCE ACLs. See Types of DCE ACL entries for other types of DCE ACL entries that are supported.

Kerberos V4 ACLs

The format of these ASCII text files is explained in the sysctl.acl section of the book PSSP: Command and Technical Reference.

Sysctl uses the following ACLs when the Kerberos V4 authentication method is in use:

The following is a sample Sysctl ACL file:

_principal sarah@TESTCELL.ABC.COM
_principal joe -
_acl_file /etc/mycmd.acl

This ACL includes entries for granting access to Kerberos V4 principal sarah and denying access to joe. The last entry names a file, that contains additional ACL entries.

The root user owns all Sysctl ACL files and is responsible for distributing the file to all nodes that share the same set of Sysctl resources. You can update an ACL file on multiple hosts in parallel using the Sysctl procedures for ACL file management. If you do not use those tools, you might want to use file collections to maintain configuration and ACL files. You can use the authenticated pcp command to securely copy files to multiple SP nodes. See Chapter 7, Managing file collections.

Log file

The /var/adm/SPlogs/sysctl/sysctld.log file is a logging file to which the Sysctl daemon (sysctld) writes. It logs the invocation of each Sysctl command. This is helpful for debugging. See the sysctld man page for information on specifying log file path names.


Client requests from systems running earlier versions than PSSP 3.2 do not provide the AIX user name, so the client is anonymous.

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