Solaris Resource Manager 1.3 System Administration Guide

PAM Subsystem

Beginning with the Solaris 2.6 release, Solaris systems support the Pluggable Authentication Module (PAM). Whenever a user requests an operation that involves changing or setting the user's identity (such as logging in to the system, invoking an 'r' command such as rcp or rsh, using ftp, or using su), a set of configurable modules are used to provide authentication, account management, credentials management, and session management. Solaris Resource Manager provides a PAM module for login accounting and modifying the behavior of su.

The program used to request the operation is called a service.

The PAM system as a whole is documented in the man pages pam(3), pam.conf(4), pam_unix(5), and pam_srm(5SRM).

In Solaris Resource Manager, the PAM module provides account management and session management functions. The behavior of PAM can be controlled by editing the file /etc/pam.conf. For normal Solaris Resource Manager behavior, the Solaris Resource Manager PAM module should be configured as requisite for all login-like services for session management, and as requisite for account management for all PAM services. Usually, the Solaris Resource Manager module should be placed after all other required and requisite modules, and before any other sufficient or optional modules.

Upon installation, Solaris Resource Manager edits /etc/pam.conf to provide a suitable behavior. It inserts lines such as these for each service (including other) that already has session or account management configured:

login account requisite nolnode=/etc/srm/nolnode 
other session requisite
other account requisite nolnode=/etc/srm/nolnode

The first line specifies that for service login, the module is to be used to provide account management functionality, that it must allow login if login is to succeed, and it is to be given the argument nolnode=/etc/srm/nolnode. See pam.conf(4) for a full explanation of the various control flags (required, requisite, optional, and sufficient).

The second line says that the login service will use the module for session management.

The full list of supported arguments for Solaris Resource Manager account and session management modules is found in pam_srm(5SRM).

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.


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.


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.


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).


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


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


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.


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:

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

Session Management

For login-like services (those that create an entry in the utmp file), the session management facilities of PAM are invoked as well as the account management facilities if both are configured in /etc/pam.conf.

The Solaris Resource Manager product's session management handles charging for devices. It looks to see if the user has exceeded the connect-time limit, or has the onelogin flag evaluate to set and is already logged in, and if so, prevents login.

Otherwise, it generates a message to the limdaemon process to inform it of the login and the configured cost for the terminal being used. It then informs the kernel that the current process is a login header process, and that the limdaemon process must be notified when it expires.

The limdaemon process then tracks connect-time limits and issues warnings if they are about to be exceeded.