Next: LDAP Up: PAM Pluggable Authentication Modules Previous: Example configuration file entries

Subsections

• pam_unix.so
• pam_nologin.so

---

Basic PAM modules

pam_unix.so

This module provides traditional Unix authentication, password management, and user account setup. It uses standard system calls to retrieve and set password and account information, and relies on /etc/shadow and /etc/passwd.

account

 

Establishes the validity of the user's account and password and may offer advice on changing the user's password, or force a password change. The actions this module performs are controlled by the /etc/passwd and /etc/shadow files.

Arguments: audit, debug.

auth

 

This component of the module checks the user's password against the password databases. Configuration for this component is done in /etc/nsswitch.conf. An additional binary, unix_chkpwd, is used to allow the component to read protected databases without requiring the whole module to be setuid root.

Arguments: audit, debug, nodelay, nullok, try_first_pass, use_first_pass.

password

 

This component changes the user's password. The module pam_cracklib.so can be stacked with this component to check password security.

Arguments: audit, bigcrypt, debug, md5, nis, not_set_pass, nullok, remember, try_first_pass, use_authtok, and use_first_pass.

session

 

This component logs the user name and session type to syslog, at the start and end of the user's session. There are no arguments to this component.

arguments

 

• audit - A more extensive form of debug
• bigcrypt - Use the DEC "C2" extension to crypt().
• debug - Log information using syslog
• md5 - Use md5 encryption instead of crypt().
• nis - Use NIS (Network Information Service) passwords.
• nodelay - By default, the module requests a delay-on-failure of a second. This argument overrides the default.
• not_set_pass - Don't use the passwords from other stacked modules. Don't give the new password to other stacked modules.
• nullok - By default, if the official password is blank, the authentication fails. This argument overrides the default.
• remember (remember=n) - Save n recent passwords to prevent the user from alternating passwords.
• try_first_pass - Use the password from the previous stacked auth module, and prompt for a new password if the retrieved password is blank or incorrect.
• use_authtok - Set the new password to the one provided by a previous module.
• use_first_pass - Use the result from the previous stacked auth module, never prompts the user for a password, fails if the result was a fail.

pam_access.so

 

This module intercepts the user's name and password. If the name is ``ftp'' or ``anonymous'', the user's password is broken up at the `@' delimiter into a PAM_RUSER and a PAM_RHOST part; these pam-items being set accordingly. The username is set to ``ftp''. In this case the module succeeds. Alternatively, the module sets the PAM_AUTHTOK item with the entered password and fails.

The behavior of the module can be modified with the following flags:

• debug - log more information to with syslog(3).
• users=XXX,YYY,... - instead of ``ftp'' or ``anonymous'', provide anonymous login to the comma separated list of users; ``XXX,YYY,...''. Should the applicant enter one of these usernames the returned username is set to the first in the list; ``XXX''.
• ignore - pay no attention to the email address of the user (if supplied). 

pam_chroot.so

 

This module is intended to provide a transparent wrapper around the average user, one that puts them in a fake file-system (eg, their '/' is really /some/where/else).

Useful if you have several classes of users, and are slightly paranoid about security. Can be used to limit who else users can see on the system, and to limit the selection of programs they can run.

pam_console.so

 

This module implements a console permission scheme similar to Solaris' logindevperms. Allows for the permissioning of certain devices and files at login and logout time. 

pam_cracklib.so

 

his module can be plugged into the password stack of a given application to provide some plug-in strength-checking for passwords.

This module works in the following manner: it first calls the Cracklib routine to check the strength of the password; if crack likes the password, the module does an additional set of strength checks. These checks are:

• Palindrome - Is the new password a palindrome of the old one?
• Case Change Only - Is the new password the the old one with only a change of case?
• Similar - Is the new password too much like the old one? This is primarily controlled by one argument, difok which is a number of characters that if different between the old and new are enough to accept the new password, this defaults to 10 or 1/2 the size of the new password whichever is smaller. To avoid the lockup associated with trying to change a long and complicated password, difignore is available. This argument can be used to specify the minimum length a new password needs to be before the difok value is ignored. The default value for difignore is 23.
• Simple - Is the new password too small? This is controlled by 5 arguments minlen, dcredit, ucredit, lcredit, and ocredit. See the section on the arguments for the details of how these work and there defaults.
• Rotated - Is the new password a rotated version of the old password?
• Already used - Was the password used in the past? Previously used passwords are to be found in /etc/security/opasswd.

This module with no arguments will work well for standard unix password encryption. With md5 encryption, passwords can be longer than 8 characters and the default settings for this module can make it hard for the user to choose a satisfactory new password. Notably, the requirement that the new password contain no more than 1/2 of the characters in the old password becomes a non-trivial constraint. For example, an old password of the form "the quick brown fox jumped over the lazy dogs" would be difficult to change... In addition, the default action is to allow passwords as small as 5 characters in length. For a md5 systems it can be a good idea to increase the required minimum size of a password. One can then allow more credit for different kinds of characters but accept that the new password may share most of these characters with the old password.

pam_deny.so

 

This module can be used to deny access. It always indicates a failure to the application through the PAM framework. As is commented in the overview section above, this module might be suitable for using for default (the OTHER) entries. 

pam_env.so

 

This module allows you to (un)set arbitrary environment variables using fixed strings, the value of previously set environment variables and/or PAM_ITEMs.

All is controlled via a configuration file (by default, /etc/security/pam_env.conf but can be overridden with conffile argument). Each line starts with the variable name, there are then two possible options for each variable DEFAULT and OVERRIDE. DEFAULT allows an administrator to set the value of the variable to some default value, if none is supplied then the empty string is assumed. The OVERRIDE option tells pam_env that it should enter in its value (overriding the default value) if there is one to use. OVERRIDE is not used, "" is assumed and no override will be done.

VARIABLE [DEFAULT=[value]] [OVERRIDE=[value]]

(Possibly non-existent) environment variables may be used in values using the ${string} syntax and (possibly non-existent) PAM_ITEMs may be used in values using the @{string} syntax. Both the $ and @ characters can be backslash-escaped to be used as literal values (as in \$. Double quotes may be used in values (but not environment variable names) when white space is needed the full value must be delimited by the quotes and embedded or escaped quotes are not supported.

This module can also parse a file with simple KEY=VAL pairs on separate lines (/etc/environment by default). You can change the default file to parse, with the envfile flag and turn it on or off by setting the readenv flag to 1 or 0 respectively.

The behavior of this module can be modified with one of the following flags:

• debug - write more information to syslog(3).
• conffile=filename - by default the file /etc/security/pam_env.conf is used as the configuration file. This option overrides the default. You must supply a complete path + file name.
• envfile=filename - by default the file /etc/environment is used to load KEY=VAL pairs directly into the env. This option overrides the default. You must supply a complete path + file name.
• readenv=0|1 - turns on or off the reading of the file specified by envfile (0 is off, 1 is on). By default this option is on. 

pam_filter.so

 

Each component of the module has the potential to invoke the desired filter. The filter is always execv(2)d with the privilege of the calling application and not that of the user. For this reason it cannot usually be killed by the user without closing their session.

The behavior of the module can be significantly altered by the arguments passed to it in the Linux-PAM configuration file:

• debug - this option increases the amount of information logged to syslog(3) as the module is executed.
• new_term - the default action of the filter is to set the PAM_TTY item to indicate the terminal that the user is using to connect to the application. This argument indicates that the filter should set PAM_TTY to the filtered pseudo-terminal.
• non_term - don't try to set the PAM_TTY item.
• runX - in order that the module can invoke a filter it should know when to invoke it. This argument is required to tell the filter when to do this. The arguments that follow this one are respectively the full pathname of the filter to be run and any command line arguments that the filter might expect.

Permitted values for X are 1 and 2. These indicate the precise time that the filter is to be run. To understand this concept it will be useful to have read the Linux-PAM Module developer's guide. Basically, for each management group there are up to two ways of calling the module's functions.

In the case of the authentication and session components there are actually two separate functions. For the case of authentication, these functions are _authenticate and _setcred - here run1 means run the filter from the _authenticate function and run2 means run the filter from _setcred. In the case of the session modules, run1 implies that the filter is invoked at the _open_session stage, and run2 for _close_session.

For the case of the account component. Either run1 or run2 may be used.

For the case of the password component, run1 is used to indicate that the filter is run on the first occasion _chauthtok is run (the PAM_PRELIM_CHECK phase) and run2 is used to indicate that the filter is run on the second occasion (the PAM_UPDATE_AUTHTOK phase).

pam_ftp.so

 

This module intercepts the user's name and password. If the name is ``ftp'' or ``anonymous'', the user's password is broken up at the `@' delimiter into a PAM_RUSER and a PAM_RHOST part; these pam-items being set accordingly. The username (PAM_USER) is set to ``ftp''. In this case the module succeeds. Alternatively, the module sets the PAM_AUTHTOK item with the entered password and fails.

The behavior of the module can be modified with the following flags:

• debug - log more information to with syslog(3).
• users=XXX,YYY,... - instead of ``ftp'' or ``anonymous'', provide anonymous login to the comma separated list of users; ``XXX,YYY,...''. Should the applicant enter one of these usernames the returned username is set to the first in the list; ``XXX''.
• ignore - pay no attention to the email address of the user (if supplied).

pam_group.so

 

This module does not authenticate the user, but instead it grants group memberships (in the credential setting phase of the authentication module) to the user. Such memberships are based on the service they are applying for. The group memberships are listed in text form in the /etc/security/group.conf file.

pam_issue.so

 

This module allows you to prepend an issue file to the username prompt. It also by default parses escape codes in the issue file similar to some common getty's (using \x format).

Recognized escapes:

• d - current date
• s - operating system name
• l - name of this tty
• m - architecture of this system (i686, sparc, powerpc, ...)
• n - hostname of this system
• o - domainname of this system
• r - release number of the operation system (eg. 2.2.12)
• t - current time
• u - number of users currently logged in
• U - same as u, except it is suffixed with "user" or "users" (eg. "1 user" or "10 users"
• v - version/build-date of the operating system (eg. "#3 Mon Aug 23 14:38:16 EDT 1999" on Linux).

The behavior of this module can be modified with one of the following flags:

• issue - the file to output if not using the default
• noesc - turns off escape code parsing 

pam_krb5.so

This module allows Kerberos 5 authentication

pam_lastlog.so

 

This module can be used to provide a ``Last login on ...'' message. when the user logs into the system from what ever application uses the PAM libraries. In addition, the module maintains the /var/log/lastlog file.

The behavior of this module can be modified with one of the following flags:

• debug - write more information to syslog(3).
• nodate - neglect to give the date of the last login when displaying information about the last login on the system.
• noterm - neglect to display the terminal name on which the last login was attempt.
• nohost - neglect to indicate from which host the last login was attempted.
• silent - neglect to inform the user about any previous login: just update the /var/log/lastlog file.
• never - if the /var/log/lastlog file does not contain any old entries for the user, indicate that the user has never previously logged in with a ``welcome..." message.

pam_ldap.so

 

This is a relatively new module that allows the use of ldap instead of something like NIS or NIS+ to do distributed authentication.

pam_limits.so

 

Through the contents of the configuration file, /etc/security/limits.conf, resource limits are placed on users' sessions. Users of uid=0 are not affected by this restriction.

The behavior of this module can be modified with the following arguments:

• debug - verbose logging to syslog(3).
• conf=/path/to/file.conf - indicate an alternative limits configuration file to the default.
• change_uid - change real uid to the user for who the limits are set up. Use this option if you have problems like login not forking a shell for user who has no processes. Be warned that something else may break when you do this.
• utmp_early - some broken applications actually allocate a utmp entry for the user before the user is admitted to the system. If some of the services you are configuring PAM for do this, you can selectively use this module argument to compensate for this behavior and at the same time maintain system-wide consistency with a single limits.conf file. 

pam_listfile

 

The module gets the item of the type specified - user specifies the username, PAM_USER; tty specifies the name of the terminal over which the request has been made, PAM_TTY; rhost specifies the name of the remote host (if any) from which the request was made, PAM_RHOST; and ruser specifies the name of the remote user (if available) who made the request, PAM_RUSER - and looks for an instance of that item in the file filename. filename contains one line per item listed. If the item is found, then if sense=allow, PAM_SUCCESS is returned, causing the authorization request to succeed; else if sense=deny, PAM_AUTH_ERR is returned, causing the authorization request to fail.

If an error is encountered (for instance, if filename does not exist, or a poorly-constructed argument is encountered), then if onerr=succeed, PAM_SUCCESS is returned, otherwise if onerr=fail, PAM_AUTH_ERR or PAM_SERVICE_ERR (as appropriate) will be returned.

An additional argument, apply=, can be used to restrict the application of the above to a specific user (apply=username) or a given group (apply=@groupname). This added restriction is only meaningful when used with the tty, rhost and shell items.

Besides this last one, all arguments should be specified; do not count on any default behavior, as it is subject to change.

No credentials are awarded by this module.

Classic ``ftpusers'' authentication can be implemented with this entry in /etc/pam.d/ftp

auth required pam_listfile.so onerr=succeed item=user sense-deny file=/etc/ftpusers

Note, users listed in /etc/ftpusers file are (counterintuitively) not allowed access to the ftp service.

pam_mail.so

 

This module provides the ``you have new mail'' service to the user. It can be plugged into any application that has credential hooks. It gives a single message indicating the newness of any mail it finds in the user's mail folder. This module also sets the Linux-PAM environment variable, MAIL, to the user's mail directory.

The behavior of this module can be modified with one of the following flags:

• debug - write more information to syslog(3).
• dir=pathname - look for the users' mail in an alternative directory given by pathname. The default location for mail is /var/spool/mail. Note, if the supplied pathname is prefixed by a `~', the directory is interpreted as indicating a file in the user's home directory.
• nopen - instruct the module to not print any mail information when the user's credentials are acquired. This flag is useful to get the MAIL environment variable set, but to not display any information about it.
• close - instruct the module to indicate if the user has any mail at the as the user's credentials are revoked.
• noenv - do not set the MAIL environment variable.
• empty - indicate that the user's mail directory is empty if this is found to be the case.
• hash=hashcount - mail directory hash depth. For example, a hashcount of 2 would make the mailfile be /var/spool/mail/u/s/user.
• standard - old style "You have..." format which doesn't show the mail spool being used. this also implies "empty"
• quiet - only report when there is new mail. 

pam_mkhomedir.so

 

This module is useful for distributed systems where the user account is managed in a central database (such as NIS, NIS+, or LDAP) and accessed through multiple systems. It frees the administrator from having to create a default home directory on each of the systems by creating it upon the first successfully authenticated login of that user. The skeleton directory (usually /etc/skel/) is used to copy default files and also set's a umask for the creation.

The behavior of this module can be modified with one of the following flags:

• skel - The skeleton directory for default files to copy to the new home directory.
• umask - An octal for of the same format as you would pass to the shells umask command. 

pam_motd.so

 

his module allows you to have arbitrary motd's (message of the day) output after a successful login. By default this file is /etc/motd, but is configurable to any file.

The behavior of this module can be modified with one of the following flags:

• motd - the file to output if not using the default. 

pam_nologin.so

Provides standard Unix nologin authentication. If the file /etc/nologin exists, only root is allowed to log in; other users are turned away with an error message (and the module returns PAM_AUTH_ERR or PAM_USER_UNKNOWN). All users (root or otherwise) are shown the contents of /etc/nologin.

If the file /etc/nologin does not exist, this module defaults to returning PAM_IGNORE, but the successok module argument causes it to return PAM_SUCCESS in this case.

The administrator can override the default nologin file with the file=pathname module argument.

pam_permit.so

 

No matter what management group, the action of this module is to simply return PAM_SUCCESS - operation successful.

In the case of authentication, the user's name will be acquired. Many applications become confused if this name is unknown.

pam_pwdb.so

 

This module is a pluggable replacement for the pam_unix_.. modules. It uses the generic interface of the Password Database library libpwdb.

The debug argument makes the accounting functions of this module syslog(3) more information on its actions. (Remaining arguments supported by the other functions of this module are silently ignored, but others are logged as errors through syslog(3)).

Based on the following pwdb_elements: expire; last_change; max_change; defer_change; warn_change, this module performs the task of establishing the status of the user's account and password. In the case of the latter, it may offer advice to the user on changing their password or, through the PAM_AUTHTOKEN_REQD return, delay giving service to the user until they have established a new password. The entries listed above are documented in the Password Database Library Guide (see pointer above). Should the user's record not contain one or more of these entries, the corresponding shadow check is not performed.

pam_rhosts_auth.so

 

his module performs the standard network authentication for services, as used by traditional implementations of rlogin and rsh etc.

The authentication mechanism of this module is based on the contents of two files; /etc/hosts.equiv (or _PATH_HEQUIV in #include <netdb.h>) and ~/.rhosts. Firstly, hosts listed in the former file are treated as equivalent to the localhost. Secondly, entries in the user's own copy of the latter file is used to map "remote-host remote-user" pairs to that user's account on the current host. Access is granted to the user if their host is present in /etc/hosts.equiv and their remote account is identical to their local one, or if their remote account has an entry in their personal configuration file.

Some restrictions are applied to the attributes of the user's personal configuration file: it must be a regular file (as defined by S_ISREG(x) of POSIX.1); it must be owned by the superuser or the user; it must not be writable by any user besides its owner.

The module authenticates a remote user (internally specified by the item PAM_RUSER) connecting from the remote host (internally specified by the item PAM_RHOST). Accordingly, for applications to be compatible this authentication module they must set these items prior to calling pam_authenticate(). The module is not capable of independently probing the network connection for such information.

In the case of root-access, the /etc/host.equiv file is ignored unless the hosts_equiv_rootok option should be used. Instead, the superuser must have a correctly configured personal configuration file.

The behavior of the module is modified by flags:

• debug - log more information to syslog(3). (XXX - actually, this module does not do any logging currently, please volunteer to fix this!)
• no_warn - do not give verbal warnings to the user about failures etc. (XXX - this module currently does not issue any warnings, please volunteer to fix this!)
• no_hosts_equiv - ignore the contents of the /etc/hosts.equiv file.
• hosts_equiv_rootok - allow the use of /etc/hosts.equiv for superuser. Without this option /etc/hosts.equiv is not consulted for the superuser account. This option has no effect if the no_hosts_equiv option is used.
• no_rhosts - ignore the contents of all user's personal configuration file ~/.rhosts.
• privategroup - normally, the ~/.rhosts file must not be writable by anyone other than its owner. This option overlooks group write access in the case that the group owner of this file has the same name as the user being authenticated. To lessen the security problems associated with this option, the module also checks that the user is the only member of their private group.
• promiscuous - A host entry of `+' will lead to all hosts being granted access. Without this option, '+' entries will be ignored. Note, that the debug option will syslog a warning in this latter case.
• suppress - This will prevent the module from syslog(3)ing a warning message when this authentication fails. This option is mostly for keeping logs free of meaningless errors, in particular when the module is used with the sufficient control flag.

pam_rootok.so

 

This module is for use in situations where the superuser wishes to gain access to a service without having to enter a password.

This module authenticates the user if their uid is 0. Applications that are created setuid-root generally retain the uid of the user but run with the authority of an enhanced effective-uid. It is the real uid that is checked.

pam_securetty.so

 

Provides standard Unix securetty checking, which causes authentication for root to fail unless PAM_TTY is set to a string listed in the /etc/securetty file. For all other users, it succeeds.

For canonical usage, should be listed as a required authentication method before any sufficient authentication methods.

pam_shells.so

 

: check for the existence of a user's shell in /etc/shells

pam_stress.so

 

: a stress testing PAM module

pam_tally.so

 

This module maintains a count of attempted accesses, can reset count on success, can deny access if too many attempts fail.

pam_tally comes in two parts: pam_tally.so and pam_tally. The former is the PAM module and the latter, a stand-alone program. pam_tally is an (optional) application which can be used to interrogate and manipulate the counter file. It can display users' counts, set individual counts, or clear all counts. Setting artificially high counts may be useful for blocking users without changing their passwords. For example, one might find it useful to clear all counts every midnight from a cron job.

The counts file is organized as a binary-word array, indexed by uid. You can probably make sense of it with od, if you don't want to use the supplied application.

Note, there are some outstanding issues with this module: pam_tally is very dependent on getpw*() - a database of usernames would be much more flexible; the `keep a count of current logins' bit has been #ifdef'd out and you can only reset the counter on successful authentication, for now.

The authentication component of this module increments the attempted login counter.

pam_time.so

 

Running a well regulated system occasionally involves restricting access to certain services in a selective manner. This module offers some time control for access to services offered by a system. Its actions are determined with a configuration file. This module can be configured to deny access to (individual) users based on their name, the time of day, the day of week, the service they are applying for and their terminal from which they are making their request.

This module bases its actions on the rules listed in its configuration file: /etc/security/time.conf. Each rule has the following form,

services;ttys;users;times

In words, each rule occupies a line, terminated with a newline or the beginning of a comment; a `#'. It contains four fields separated with semicolons, `;'. The fields are as follows:

• services - a logic list of service names that are affected by this rule.
• ttys - a logic list of terminal names indicating those terminals covered by the rule.
• user - a logic list of usernames to which this rule applies

By a logic list we mean a sequence of tokens (associated with the appropriate PAM_ item), containing no more than one wildcard character; `*', and optionally prefixed with a negation operator; `!'. Such a sequence is concatenated with one of two logical operators: & (logical AND) and | (logical OR). Two examples are: !morgan&!root, indicating that this rule does not apply to the user morgan nor to root; and tty*&!ttyp*, which indicates that the rule applies only to console terminals but not pseudoterminals.

times - a logic list of times at which this rule applies. The format of each element is a day/time-range. The days are specified by a sequence of two character entries. For example, MoTuSa, indicates Monday Tuesday and Saturday. Note that repeated days are unset; MoTuMo indicates Tuesday, and MoWk means all weekdays bar Monday. The two character combinations accepted are,

Mo Tu We Th Fr Sa Su Wk Wd Al

The last two of these being weekend days and all 7 days of the week respectively.

The time range part is a pair of 24-hour times, HHMM, separated by a hyphen - indicating the start and finish time for the rule. If the finish time is smaller than the start time, it is assumed to apply on the following day. For an example, Mo1800-0300 indicates that the permitted times are Monday night from 6pm to 3am the following morning.

Note, that the given time restriction is only applied when the first three fields are satisfied by a user's application for service.

For convenience and readability a rule can be extended beyond a single line with a `\newline'. 

pam_unix.so

 

This is the standard Unix authentication module. It uses standard calls from the system's libraries to retrieve and set account information as well as authentication. Usually this is obtained from the /etc/passwd and the /etc/shadow file as well if shadow is enabled.

he debug argument makes the accounting functions of this module syslog(3) more information on its actions. (Remaining arguments supported by the other functions of this module are silently ignored, but others are logged as errors through syslog(3)). The audit argument causes even more logging.

Based on the following shadow elements: expire; last_change; max_change; min_change; warn_change, this module performs the task of establishing the status of the user's account and password. In the case of the latter, it may offer advice to the user on changing their password or, through the PAM_AUTHTOKEN_REQD return, delay giving service to the user until they have established a new password. The entries listed above are documented in the GNU Libc info documents. Should the user's record not contain one or more of these entries, the corresponding shadow check is not performed.

pam_userdb.so

 

Look up users in a .db database and verify their password against what is contained in that database.

This module is used to verify a username/password pair against values stored in a Berkeley DB database. The database is indexed by the username, and the data fields corresponding to the username keys are the passwords, in unencrypted form, so caution must be exercised over the access rights to the DB database itself..

The module will read the password from the user using the conversation mechanism. If you are using this module on top of another authentication module (like pam_pwdb;) then you should tell that module to read the entered password from the PAM_AUTHTOK field, which is set by this module.

The action of the module may be modified from this default by one or more of the following flags in the /etc/pam.d/<service> file.

• debug - Supply more debugging information to syslog(3).
• icase - Perform the password comparisons case insensitive.
• dump - dump all the entries in the database to the log (eek, don't do this by default!)
• db=XXXX - use the database found on pathname XXXX. Note that Berkeley DB usually adds the needed filename extension for you, so you should use something like /etc/foodata instead of /etc/foodata.db.

pam_warn.so

 

This module is principally for logging information about a proposed authentication or application to update a password.

Log the service, terminal, user, remote user and remote host to syslog(3). The items are not probed for, but instead obtained from the standard pam-items.

pam_wheel.so

 

This module is used to enforce the so-called wheel group. By default, it permits root access to the system if the applicant user is a member of the wheel group (better described as the group with group-id 0).

The action of the module may be modified from this default by one or more of the following flags in the /etc/pam.conf file.

• debug - Supply more debugging information to syslog(3).
• use_id - This option modifies the behavior of the module by using the current uid of the process and not the getlogin(3) name of the user. This option is useful for being able to jump from one account to another, for example with 'su'.
• trust - This option instructs the module to return PAM_SUCCESS should it find the user applying for root privilege is a member of the wheel group. The default action is to return PAM_IGNORE in this situation. By using the trust option it is possible to arrange for wheel-group members to become root without typing a password. USE WITH CARE.
• deny - This is used to reverse the logic of the module's behavior. If the user is trying to get uid=0 access and is a member of the wheel group, deny access (for the wheel group, this is perhaps nonsense!): it is intended for use in conjunction with the group= argument...
• group=XXXX - Instead of checking the gid=0 group, use the user's XXXX group membership for the authentication. Here, XXXX is the name of the group and not its numeric identifier.

To allow only members of the wheel group to become root through su, use the following line in /etc/pam.d/su:

auth required /lib/security/pam_wheel.so use_uid

pam_warn.so

 

This module logs information about an authentication or password change attempt to syslog.

This module has no arguments, and only auth and password components. Log the service, terminal, user, remote user and remote host to syslog(3). The items are not probed for, but instead obtained from the standard pam-items.

pam_xauth.so

 

This module is designed to forward xauth keys (sometimes referred to as "cookies") between users.

Without pam_xauth, when xauth is enabled and a user uses the su command to assume superuser privileges, that user is not able to run X commands as root without somehow giving root access to the xauth key used for the current X session. pam_xauth solves the problem by forwarding the key from the user running su (the source user) to the user whose identity the source user is assuming (the target user) when the session is created, and destroying the key when the session is torn down.

---

Next: LDAP Up: PAM Pluggable Authentication Modules Previous: Example configuration file entries
2005-05-04