Sysctl is contained in the installation option file ssp.sysctl. This is installed when you install the SP system management software. See the PSSP: Installation and Migration Guide for more information.
The basic procedure for configuring the system for Sysctl follows. Most of the steps are performed for you, either by the installation process or when you run setup_authent (both processes are described in PSSP: Installation and Migration Guide).
When you install ssp.sysctl the following steps happen automatically:
sysctl 6680/tcp sysctld
sysctld:2:once:/usr/bin/startsrc -s sysctld
Here are the configuration steps that you need to perform:
When the server is operational, you can manipulate Sysctl ACLs through the Sysctl built-in commands described in Table 7.
For you to be at this point, your Sysctl server has been configured. After obtaining credentials as appropriate for DCE or Kerberos V4, whichever apply, you should be able to perform Sysctl tasks. As a simple test, enter the command:
sysctl whoami -v
The normal system response is three lines of output showing your DCE identity, your Kerberos V4 identity, and your AIX user ID. If DCE is in use for authentication and you have valid DCE credentials, the first line shows your DCE principal name. If Kerberos V4 is in use for authentication and you have valid Kerberos V4 credentials, the second line shows your Kerberos V4 principal name. The third line shows your AIX user ID. The output looks something like this:
DCE: /.../abc.com/andrew
K4: andrew@abc.com
AIX: andrew
If you do not have credentials, the system response depends on whether the server uses any authentication methods for SP trusted services. If the server does not use an authentication method, it is not concerned with credentials and the output looks something like this:
DCE:
K4:
AIX: andrew
If you do not have credentials and the server does use an authentication method, the server returns an error message informing you that you have insufficient authorization. You might have forgotten to issue the dcecp or kinit command, whichever is appropriate for the authentication method in use. If that is not the case, then either you are not authorized to perform the task or some portion of your Sysctl configuration might be incorrect.
To obtain more information, as the root user, restart the sysctld daemon with the debugging and security auditing option turned on. Do that by running the following commands:
/usr/bin/stopsrc -s sysctld
/usr/bin/startsrc -s sysctld -a "-sd -l your_debug_log_filepath"
The daemon records security and other debugging information in the log file you named.
If you suspect an authentication problem, use the klist or the k4list command for DCE or Kerberos V4 respectively, to list your current credentials. It lists your principal name and all tickets that are currently in your ticket cache, including the expiration date and time.
If you attempt a Sysctl request from a host in one security domain to a target host in another and have not set up cross-domain authentication capability, you will receive error messages in addition to the authorization failure that might be misleading. For instance, the following message indicates that DCE could not provide the client with a service ticket for the target server. It has nothing to do with whether you have issued the dce_login command.
2502-603 You do not have DCE credentials.
Server not found in Kerberos database
Similarly, this message indicates that Kerberos V4 could not provide the client with a service ticket for the target server. It has nothing to do with whether you have issued the k4init command.
2502-608 Kerberos error in krb_mk_req:
2504-008 Kerberos principal unknown
Configuration commands create read-only variables, register procedures, include other configuration files, and create classes of procedures. Configuration commands are interpreted when a server is started or restarted, and are contained in configuration files. The configuration commands are:
The include command specifies additional configuration files for the server to read. This makes it easier to manage many external command definitions by letting them be split among a hierarchical set of files. The following example causes the Sysctl server to read the contents of the specified file at initialization time:
include $buildTop/samples/sysctl/pdfpfck.cmds
The syntax of include is:
include filename
The create var command defines a read-only variable in the Sysctl server. Variables defined in the configuration file using the standard Tcl set command exist only while the configuration files are being read.
The syntax of create var is:
create var variable value [authcallback]
where:
The following example defines a variable (STARTTIME) that contains the time you started up the server:
create var STARTTIME [exec /bin/date] NONE
The create proc command defines external Sysctl procedures.
The syntax of create proc is:
create proc name args authcallback body
where:
See Developing a Sysctl application for an example of create proc.
The create class command defines classes of commands within the server. Command classes provide a way to organize commands into logical groups for clarity.
The syntax of create class is:
create class name file [authcallback]
where:
This name constitutes a tag that is prefixed to all commands defined in the command file.
For example, if a class named test is created and the class file defines a procedure named help, the procedure is created in the interpreters as test:help.
The set statement sets the value of the server variables ACL, LOG or KEY, or sets values in the Tcl env() array. The default values for the Sysctl server's ACL file, log file and Kerberos key file can be overridden by assigning values to the ACL, LOG and KEY variables in the configuration file. For example, the following line overrides the default value for the log file name:
set LOG /var/sysctld.logfile
The values assigned to the ACL, LOG and KEY variables are overridden by the optional command line arguments -a, .-l and -k on the sysctld command line. Environment variables (such as the default PATH) can also be set within the configuration file by assigning values to the env() array. For example:
set env(PATH) /usr/bin:/bin:/usr/etc:/etc
sets the PATH environment variable for the Sysctl server. The env() array is assigned an authorization callback of SYSTEM which prevents its modification from outside the Sysctl server by a request sent by a Sysctl client.
The load command dynamically loads the shared library at lib_path into memory. If the init_proc parameter is given, it is used as the library's initialization procedure. Otherwise the name of the initialization function is derived from the library name as follows:
library name init function
============ =============
libxxx.sl xxx_Init()
libxxx.a xxx_Init()
The Sysctl server exports an API that the library uses to define commands, variables, authorization callbacks and interpreter deletion callbacks. See the load help page for details.
You can include other commands in the Sysctl configuration file. These commands are executed by the server when it is started (or restarted).
Sysctl provides an extremely flexible authentication mechanism to allow you to restrict the use of registered Sysctl procedures to any easily defined subset of users. Authorization callbacks are the means by which this authentication is implemented. As previously discussed, Sysctl includes four supplied authorization callbacks which provide the following authorization levels:
As an administrator you can develop a procedure with an authorization level that does not fit one of the supplied authorization callbacks. To do this, write your own authorization callback. Here is an example of a custom authorization callback:
create proc scdate {} SYSTEM {exec /bin/date}
create proc RCRAUTH {cmdName} SYSTEM {
global SCUSER
global SCPRINCIPAL
if {$SCUSER != "rcr"} {
svclog "Denying \"$cmdName\" access for user $SCPRINCIPAL"
error "Authorization denied!"
} else {
svclog "Authorizing \"$cmdName\" access for user $SCPRINCIPAL"
return "Authorization OK!"
}
}
create proc rcrdate {} {RCRAUTH rcrdate} {scdate}
This example contains the definition of three procedures:
The supplied ACL authorization callback is used to check for the remote user's principal name in an ACL file. If this callback is used without any parameters then the ACL file named by the ACL variable (normally /etc/sysctl.acl) is checked. If a file name is supplied as a variable to the ACL callback, then that file is checked for the user's principal name.
This allows an authorization callback to reference an alternate ACL file in performing the authorization check:
create proc myproc {} {ACL /etc/myproc.acl} {
·
·
·
}
The previous example defines the procedure myproc, which takes no parameters, and has an authorization callback of ACL /etc/myproc.acl. This callback returns a normal result if the remote user's principal name appears in the file /etc/myproc.acl and an error return if it does not.
ACL files can be created and deleted and their contents can be manipulated and checked by using the Sysctl commands aclcreate, acldestroy, acladd, acldelete, acllist, aclcheck and aclrecreate (see the Sysctl help information for these commands).