Account Management

When the Solaris Resource Manager account management PAM module gets control:

1. It determines if Solaris Resource Manager is installed and enabled, and tells the PAM system to ignore this module if it is not.

2. It determines whether the user has an lnode, and calls an administrator-configurable 'no lnode' script if not.

3. It determines whether the user has permission to use the requested service and device.

4. It determines whether the user has exceeded the warnings limit, and refuses permission to log in if this is the case.

5. It calls an administrator-configurable 'every login' script.

If any of these steps fail, the remainder are not performed, and the Solaris Resource Manager account management PAM module denies use of the service. An explanatory message is passed to the user through the service where possible.

Scripts

The default 'missing lnode' script will create an lnode for the user and send mail notifying the system administrator that this has been done. The default script is /etc/srm/nolnode, but this can be changed by editing the file /etc/pam.conf and changing the value of the nolnode option on Solaris Resource Manager account management module lines. The 'every login' script is not usually configured. However, it can be configured by adding an [[everylogin=pathname]] option to any Solaris Resource Manager account management module in /etc/pam.conf. Scripts are invoked as the root user. Standard input, output, and error are closed. If a script exits non-zero, access will be denied. All information is passed as environment variables, which are derived directly from information passed to PAM from the service.

USER

The login name supplied to the program. It has been authenticated by looking it up in the password map; if not present, the account management module will already have returned an error code to PAM.

UID

The UID of the user being authenticated. For services that change UID (such as su), this is the UID of the user invoking the service; for services that set UID (such as login), this is the target UID (that of USER).

RHOST

For access attempts across a network, this variable contains the name of the host where the attempt originated. Its value is otherwise implementation dependent.

SERVICE

The name of the access service, for example, rsh, login, and ftp.

TTY

The name of the TTY on which the service is being invoked. Some services that do not (strictly speaking) have a controlling terminal (such as ftp) will fill this variable with process information (for example, ftp12345, where 12345 is the process identifier (PID) of ftpd; others leave it empty or replace it with the service name.

DEBUG

If debug was specified in the pam.conf file, DEBUG is set to true; otherwise it is set to false. No other environment variables are set, so any script must set its own PATH variable if required.

The default 'no lnode' script creates the lnode in the default scheduling group (other if such a user exists in the password map, otherwise root) and mails the system administrator a reminder to move the new lnode into the appropriate place in the scheduling hierarchy. For a sample script, see Default 'no lnode' Script.

PAM Interaction With Device Groups

The Solaris Resource Manager PAM module looks up the terminal and service names in the device hierarchy, and returns a 'permission denied' message to its invoker if limits are exceeded or if a device flag evaluates to set.

The device categories examined are terminal for the terminal name, and services for the kind of service requested. For example, an rlogin attempt may try to use a file in the network device group, so the flags tested for the user (assuming all flags are set to group) are as shown below. These flags are checked in order:

• terminal.flag.network

• terminal.flag.all

• services.flag.rlogin

• services.flag.netservices

Access is permitted only if they all evaluate to set. In addition, limits will be checked for the corresponding categories (terminal and services).