May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

PAM (Pluggable authentication modules)

News Authentication and Accounts Security

Recommended Links

Selected PAM Modules Papers Reference
Authentication token manipulation module-type PAM wheel SecurID Password crackers Kerberos
Linux PAM Solaris PAM Stanford compromise History Humor Etc

PAM (the Pluggable Authentication Module) is a unified authentication scheme introduced by Sun in Solaris (released as an undocumented feature in Solaris 2.3 ) and later re-implemented in other commercial Unixes and most open source OSes (BSD variants, Linux, etc).  PAM permits modularization (plus some refactoring) of the old codebase.  In old versions of Unix the authentication code was not modular and was imbedded in login, su, passwd and all the other programs that perform authentication. If you wanted to make any change to the database in which passwords were stored, or change the ground rules for how authentication was done, you had to modify and rebuild all those programs.

It is rather primitive system  which can now be a textbook example of the danger of inventing ad hoc languages.  In Linux complexity of PAM (over-complexity to be exact) exceeds the ability of regular administrators to understand it by large margin. As such from a pretty straightforward security measure Linux PAM mutated into a something in between a security mechanism and a security hole.

This is  especially true if you try to change something without understanding of complex interplay between modules (can we envision appearance "Linux PAM specialist" in job adds ?). Also PAM include files is classic example of road to hell paved with good intensions: they provide additional capability for intruder to hijack access to the system in a way that is very difficult to detect.  Just try to answer the questions below for any Linux system:

Converting this mess to a scripting language probably can improve things but it might be too late for linux with its pretty mature level of distributions and old age of OS itself.

But even with all its warts PAM was a big improvement over previous situation: it allows the system administrator to customize the authentication services that should be used for various applications.  At the core of PAM is a primitive ad-hoc assembler like PAM language that is used to connect (stack) several authentication modules, each of which can perform certain checks. A Sun original  rfc86.0 document describes it (it is slightly outdated).   You can also decide if success of the check is enough for authentication, if the failure of the check is enough for rejection and some other simple logical tests. 

PAM is configured by making appropriate modifications to one file, /etc/pam.conf (Solaris), or by editing individual control files that are located in /etc/pam.d in Linux.   Linux re-implementation of PAM is described at the Official Linux-PAM home page 

PAM allows you to change your authentication methods and requirements on the fly, and encapsulate all local authentication methods without recompiling any of your binaries.

Despite being primitive from the point of view of its the underling formal language (simple rules) the system itself is very tricky as there are a lot of behind the surface information that you need to understand.  Just look at the problem of integrating of RSA SecurID into this framework. The best way is to look for help at forums like Red Hat The pam-list Archives

The applications (typically login, ftp, dtlogin, SSH and other programs that "log a user in") are now all built to be aware of the services PAM offers -- i.e. the corresponding daemons and program knows how to get PAM to do the authentication.

PAM the authentication modules are implemented as dynamically-linked shared library files. A single standard API is used by all authentication programs, and a configuration file read at run time determines which authenticators are actually used for each program. Thus you can revise how authentication works by just installing new modules and or editing the configuration files. You don't need to rebuild the application programs.

The PAM config file formats for Linux and Solaris PAM are slightly different, and the names of the standard modules are entirely different. There are portability issues involved in writing PAM modules as well. Things to be aware of:

Typical additional things that you do with PAM is:

PAM-specific tokens in the configuration file are case insensitive. The module paths, however, are case sensitive, since they indicate a file's name and reflect the case dependence of typical file systems. The case sensitivity of the arguments to any given module is defined for each module in turn.

In addition to the lines described below, there are two special characters provided for the convenience of the system administrator: comments are preceded by a "#" and extend to the next end-of-line; also, module specification lines may be extended with a "\"-escaped newline.

If the PAM authentication module (loadable link library file) is located in the default location, then it is not necessary to specify the path. In the case of Linux, the default location is /lib/security. If the module is located outside the default, then the path must be specified as:

auth  required  /other_path/

Anatomy of /etc/pam.d Entries

A general configuration line of the /etc/pam.conf file has the following form:

service-name   module-type   control-flag   module-path   args

We explain the meaning of each of these tokens. The second (and more recently adopted) way of configuring Linux-PAM is via the contents of the /etc/pam.d/ directory. Once we have explained the meaning of the tokens, we describe this method.

service-name The name of the service associated with this entry. Frequently, the service-name is the conventional name of the given application for example, ftpd, rlogind and su, and so on.

There is a special service-name reserved for defining a default authentication mechanism. It has the name OTHER  and may be specified in either lower- or uppercase characters. Note, when there is a module specified for a named service, the OTHER  entries are ignored.


One of (currently) four types of module. The four types are as follows:


 The control-flag is used to indicate how the PAM library will react to the success or failure of the module it is associated with. Since modules can be stacked (modules of the same type execute in series, one after another), the control-flags determine the relative importance of each module. The application is not made aware of the individual success or failure of modules listed in the /etc/pam.conf file. Instead, it receives a summary success or fail response from the Linux-PAM library. The order of execution of these modules is that of the entries in the /etc/pam.conf file; earlier entries are executed before later ones. As of Linux-PAM v0.60, this control-flag can be defined with one of two syntaxes. The simpler (and historical) syntax for the control-flag is a single keyword defined to indicate the severity of concern associated with the success or failure of a specific module. There are four such keywords: required, requisite, sufficient, and optional.

The Linux-PAM library interprets these keywords in the following manner:

The more elaborate (newer) syntax is much more specific and gives the administrator a great deal of control over how the user is authenticated. This form of the control-flag is delimited with square brackets and consists of a series of value=action  tokens:

[value1=action1 value2=action2 ...]

Here, value1 is one of the following return values:

success; open_err; symbol_err; service_err; system_err; buf_err;
perm_denied; auth_err; cred_insufficient; authinfo_unavail;
user_unknown; maxtries; new_authtok_reqd; acct_expired; session_err;
cred_unavail; cred_expired; cred_err; no_module_data; conv_err;
authtok_err; authtok_recover_err; authtok_lock_busy;
authtok_disable_aging; try_again; ignore; abort; authtok_expired;
module_unknown; bad_item; and default.

The last of these (default) can be used to set the action for those return values that are not explicitly defined.

The action1 can be a positive integer or one of the following tokens: ignore; ok; done; bad; die; and reset. A positive integer, J, when specified as the action, can be used to indicate that the next J modules of the current module-type will be skipped. In this way, the administrator can develop a moderately sophisticated stack of modules with a number of different paths of execution. Which path is taken can be determined by the reactions of individual modules.

Each of the four keywords, required; requisite; sufficient; and optional, have an equivalent expression in terms of the new syntax. They are as follows:

Just to get a feel for the power of this new syntax, here is a taste of what you can do with it. With Linux-PAM-0.63, the notion of client plug-in agents was introduced. This makes it possible for PAM to support machine-machine authentication using the transport protocol inherent to the client/server application. With the [ ... value=action ... ] control syntax, it is possible for an application to be configured to support binary prompts with compliant clients, but to gracefully fail over into an alternative authentication mode for legacy applications.


The pathname of the dynamically loadable object file; the pluggable module itself. If the first character of the module path is "/", it is assumed to be a complete path. If this is not the case, the given module path is appended to the default module path: /lib/security (but see the previous notes).

The arguments are a list of tokens that are passed to the module when it is invoked, much like arguments to a typical Linux shell command. Generally, valid arguments are optional and are specific to any given module. Invalid arguments are ignored by a module; however, when encountering an invalid argument, the module is required to write an error to syslog(3). For a list of generic options, see the next section.

If you wish to include spaces in an argument, you should surround that argument with square brackets. For example:

squid auth required user=passwd_query passwd=mada \
db=eminence [query=select user_name from internet_service where \
user_name="%u" and password=PASSWORD("%p") and service="web_proxy"]

When using this convention, you can include "[" characters inside the string, and if you wish to have a "]" character inside the string that will survive the argument parsing, you should use "\[". In other words,

[..[..\]..]    -->   ..[..]..

Any line in one of the configuration files that is not formatted correctly will generally tend (erring on the side of caution) to make the authentication process fail. A corresponding error is written to the system log files with a call to syslog(3).

There is an interesting attempt to write Python bindings by Rob Riggs. Current Release 2007/04/17 10:12PM, version 0.5.0.

This release supports the core PAM API. There is still some missing functionality, but
it should implement enough of the API for most needs. There is not much in the way
of documentation at this point. If you are familiar with the PAM API, a quick glance
at the sample program should get you going.

This code is released under the GNU LGPL. Please read the file entitled 'COPYING', which is
part of the tar.gz distribution, if you are unfamiliar with the terms of the GNU Library General
Public License.  

Changes in version 0.5.0 include:

   DOWNLOAD:  PyPAM-0.5.0.tar.gz

Top Visited
Past week
Past month


Old News ;-)

[Jul 24, 2020] An introduction to Pluggable Authentication Modules (PAM) in Linux - Enable Sysadmin by Susan Lauber

Jul 22, 2020 |

Pluggable Authentication Modules (PAM) have been around since 1997. I was taught that PAM originated from Sun's Solaris, and it does appear that the first enterprise use and popularization occurred there. However, according to a 1997 article I found, the first full implementation was the Linux-PAM deployment. The article is still available from Linux Journal . The basic premise and implementation have not changed since then. There are some new keywords and many new modules, but overall the process is the same as 20 years ago.

More Linux resources

As the A in PAM indicates, PAM is about authentication. In most cases, when you log in to a system via a console or from across the network with SSH or Cockpit , PAM is involved. It doesn't matter if the user accounts are held locally or in a centralized location. For as much as it is used, it not common to manipulate the PAM configuration files directly. Other utilities do it for you. Many changes are made at installation, such as when installing the sssd RPM or using the ipa-client-install utility. The most common additional configurations can be handled by authconfig (RHEL7 and older) or authselect (RHEL8), or even through the Cockpit web interface. Most administrators do not learn about PAM configuration files until they get involved in advanced authentication and security topics.

What do we gain with PAM?

PAM separates the standard and specialized tasks of authentication from applications. Programs such as login , gdm , sshd , ftpd , and many more all want to know that a user is who they say they are, yet there are many ways to do that. A user can provide a user name and password credential which can be stored locally or remotely with LDAP or Kerberos. A user can also provide a fingerprint or a certificate as a credential. It would be painful to ask each application developer to rewrite the authentication checks for each new method. A call to PAM libraries leaves the checks to authentication experts. PAM is pluggable in that we can have different applications run different tests and modular in that we can add new methods with new libraries.

Let's look at the high-level steps taken when a locally-defined user logs into a text-based console:

There are many components to PAM

If you make a change to authentication using a program such as authconfig or authselect and want to see what changed, here are some of the places to look:

A collection of PAM libraries that perform various checks. Most of these modules have man pages to explain the use case and options available.

A collection of configuration files for applications that call libpam . These files define which modules are checked, with what options, in which order, and how to handle the result. These files may be added to the system when an application is installed and are frequently edited by other utilities.

Since there are several checks done by all applications, these files may also have include statements to call other configuration files in this directory. Most shared modules are found in the system-auth file for local authentication and the password-auth file for applications listening for remote connections.

A collection of additional configuration files for specific modules. Some modules, such as pam_access and pam_time , allow additional granularity for checks. When an application configuration file calls these modules, the checks are completed using the additional information from its corresponding supplemental configuration files. Other modules, like pam_pwquality , make it easier for other utilities to modify the configuration by placing all the options in a separate file instead of on the module line in the application configuration file.

Most security and authentication errors are reported to this log file. Permissions are configured on this file to restrict access.

man pam
This man page describes the overall process, including the types of calls and a list of files involved.

man pam.conf
This man page describes the overall format and defines keywords and fields for the pam.d configuration files.

man -k pam_
This search of man pages lists pages available for modules installed.

Wrap up

PAM allows for a much more robust authentication environment than per-application services could provide. It has been in Linux for many, many years, and is involved with nearly all user identification processes.

In the next article, I will walk through the format of the /etc/pam.d configuration files.

[Mar 3, 2008] Improve security with polyinstantiation. Using a Pluggable Authentication Module to protect private data by Robb R. Romans

Looks like Red Hat specific but probably can be adapted to other distributions.
Feb 26, 2008 | developerworks

If you're concerned about protecting world-writeable shared directories such as /tmp or /var/tmp from abuse, a Linux® Pluggable Authentication Module (PAM) can help you. The pam_namespace module creates a separate namespace for users on your system when they login. This separation is enforced by the Linux operating system so that users are protected from several types of security attacks. This article for Linux system administrators lays out the steps to enable namespaces with PAM.

To improve security, it's often wise to use more than one method of protection (also called "defense in depth"). That way, if one method is breached, another method remains operational and prevents further intrusion. This article describes a way to add another layer of depth to your security strategy: using PAM to polyinstantiate world-writeable shared directories. This means that a new instance of a directory, such as /tmp, is created for each user.

Polyinstantiation of world-writeable directories prevents the following types of attacks, as Russell Coker illustrates in "Polyinstantiation of directories in an SELinux system" (see Resources):

However, polyinstantiation does NOT prevent these types of attacks:

How PAM and polyinstantiation work

PAM creates a polyinstantiated private /tmp directory at login time within a system instance directory; this redirection is transparent to the user logging in. The user sees a standard /tmp directory and can read and write to it normally. That user cannot see any other user's (including root's) /tmp space or the actual /tmp file system.

Polyinstantiated user directories are neither hidden nor protected from the root user. If you are interested in that level of protection, SELinux can help. The configuration examples provided here should work whether or not you have enabled SELinux. See Resources for links to more information about using SELinux.

Enabling polyinstantiation

This section shows you how to enable polyinstantiation of /tmp and /var/tmp directories for users on your system. It also describes the optional configuration steps necessary to accommodate X Windows or a graphical display manager. I used Red Hat Enterprise Linux 5.1 (RHEL 5.1) to write this article, but you can try the procedures described here on any Linux distribution that includes the pam_namespace module.

First we'll edit namespace.conf.

Edit namespace.conf

The first file you'll edit is /etc/security/namespace.conf, which controls the pam_namespace module. In this file, list the directories that you want PAM to polyinstantiate on login. Some example directories are listed in the file included with PAM and are commented out. Type man namespace.conf to view a comprehensive manual page. The syntax for each line in this file is polydir instance_prefix method list_of_uids.

[Dec 10, 2007] solaris-friendly pam_cracklib

solaris-friendly pam_cracklib is a reimplementation of pam_cracklib that builds and runs on Solaris as well as Linux. It is a PAM module for checking passwords with cracklib.

[Dec 4, 2007] Project details for pam_require

pam_require is a simple Plugable Authentication Module (PAM) for Linux (and maybe other systems which use PAM). It is an account module that allows you to require a special group or user to access a service.

[Dec 1, 2007] Project details for pam_script

pam_script is a PAM that executes a script at the start and end of a session. Any PAM-aware application can use the module to perform arbitrary operations. It was originally written for cleaning up when a user logs out.

Izak Burger [contact developer]

[Nov 25, 2007] Linux-PAM released, Thorsten Kukuk

The Linux-PAM developement team is pleased to announce the release
of version

This is a bug fix release:

- misc_conv no longer blocks SIGINT; applications that don't want
user-interruptable prompts should block SIGINT themselves
- Merge fixes from Debian
- Fix parser for pam_group and pam_time

If you use pam_group or pam_time for your configurations, you
should update.

Please report bugs to the sourceforge bug tracking system.

Your Linux-PAM development team
Thorsten Kukuk, Project Manager/Release Manager SLES
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
GF: Markus Rex, HRB 16746 (AG Nuernberg)

Re Pam-list Digest, Vol 41, Issue 6

> Here are my other pam files,
> /etc/pam.d/common-auth:
> auth required
> auth sufficient use_first_pass
> auth required nullok_secure use_first_pass
> /etc/pam.d/common-pammount:
> auth       optional use_first_pass
> session    optional use_first_pass
> /etc/pam.d/common-session:
> session required
> session required umask=0022 skel=/etc/skel
> session optional
> Can someone please tell me what is going wrong?
>    Juan

IMHO pam_mount under section 'auth' doesn't make sense. Mounting devices
is a property of the session. What should pam_mount authenticate against? 
Please try and remove the 'auth' entries of pam_mount and try again.


Dr.-Ing. Andreas Schindler
Alpha Zero One Computersysteme GmbH
Frankfurter Str. 141
63303 Dreieich
Telefon 06103-57187-21
Telefax 06103-373245
schindler az1 de

Alpha Zero One Computersysteme GmbH, Brandeniusstr. 3, 44265 Dortmund
HRB 11089 Amtsgericht Dortmund, Geschäftsführer : Klaus-Jürgen Koke, Joachim Carle 
RE Pam-list Digest, Vol 41, Issue 6
In the auth section you need to authenticate the user first and if that succeeds then mount their directory. Try this:

auth sufficient
auth required nullok_secure use_first_pass
auth optional use_first_pass

When the user is authenticated either by pam_winbind or pam_unix (note the re-use of the password), then the pam_mount can also re-use the password (The password is only required if the file system is encrypted) to optionally mount the directory. If pam_mount fails for some reason the login will still succeed.

Kevin Whittier (CISSP)
Senior Linux Architect
Fleet Numerical Meteorology and Oceanography Center (FNMOC)
831 656-4603
Kevin whittier ctr navy mil 

Re Checking if PAM is used by login

On Tue, June 26, 2007 10:14, David Resnick wrote:

> Is there any method of checking if the services are compiled to use the
> PAM modules?

First of all, all Linux distributions (to my knowledge Slackware is the
only exception) use PAM for authentication (login) and password changes.

Second, you should take a look at /var/log/message (or similar) where PAM
is write log messages. For example I have the following in my log:

Jun 26 11:10:01 colws01m crond(pam_unix)[5283]: session opened for user
root by (uid=0)
Jun 26 11:10:01 colws01m crond(pam_unix)[5283]: session closed for user root


Re Pam-list Digest, Vol 38, Issue 4

pam-list-request redhat com wrote:
Send Pam-list mailing list submissions to
Re: [Pam-patches] New pam items
I can't figure out, what PAM_DEVICE should be good for. IMHO it is far
too unspecific to be really useful.

To the discussion about PAM_DISPLAY: Before all, please consider that every X-Display on a local machine (i.e. DISPLAY=x.x or localhost:x.x)
ALWAYS has an associatet TTY, because the X-Server needs a (pseudo-)device
to attach to. So, PAM_TTY and PAM_DISPLAY should be independent of each other.

By the way: why not use the PAM environment to store additional information?
Annother way could is possible using pam_set/get_data.
I've done this successfully when implementing a TACACS-to -PAM gateway.
In conjunction with a special PAM module to store and retrieve Information
i consider this a very smooth way to associate additional information with PAM.


Dr.-Ing. Andreas Schindler

PAM in Open Solaris

RBAC - Role Based Access Control at

OpenSolaris UserGroup RBAC presentation

RBAC Best Practices for OpenSolaris developers

The following best practice documents for using RBAC in developing other parts of OpenSolaris can be found in the ARC community:

Why use

PAM were created by Sun and first appeared as a public interface in Solaris 2.6. Previous versions of a very similar framework were in Solaris 2.4 and Solaris 2.5.1. Until Solaris 9 there was only one module,, that implemented the default UNIX username/password policy. In Solaris 9 we broke up that module in to a number of smaller parts:,,,,, and

Sample Modules

In the files section there are a few sample modules and programs that I (Darren Moffat) have had lying around in my home directory at Sun since I first started playing with PAM before Solaris 2.6 was released.

I originally called this, and it was one of my earliest PAM modules. I'm not proud of the way it is coded and it is an ugly hack since it uses the xauth(1) program to do its work. However I've always found it very useful, no more xhost + for me :-) I know that some Linux based distros ship with something like this but I'm pretty confident I was the first to implement it and someone else idependently came up with the idea.

This is a simple demo application that calls the PAM APIs that an application would call. I use it as a very simple test application, not really useful for anything else.

This is a PAM implementation of the check that /bin/login has hardcoded for root on the system console.

Basically this is a local file that contains usernames and/or netgroups that should either be allowed or denied access to a given service. The idea for this module came from observing the performance hit that the nsswitch passwd_compat +/- syntax can have on some systems. What most people used that for was invalidating the users shell and/or password so they couldn't login, but still allow the admin to get uid->name translations of the files the users owned on the server. This module has appeared in SunSolve articles in the past. I wrote this version of it in 1999.

[Nov 10, 2006] Pluggable Authentication Module at

PAM were created by Sun and first appeared as a public interface in Solaris 2.6. Previous versions of a very similar framework were in Solaris 2.4 and Solaris 2.5.1. Until Solaris 9 there was only one module,, that implemented the default UNIX username/password policy. In Solaris 9 we broke up that module in to a number of smaller parts:,,,,, and

Sample Modules

In the files section there are a few sample modules and programs that I (Darren Moffat) have had lying around in my home directory at Sun since I first started playing with PAM before Solaris 2.6 was released.

I originally called this, and it was one of my earliest PAM modules. I'm not proud of the way it is coded and it is an ugly hack since it uses the xauth(1) program to do its work. However I've always found it very useful, no more xhost + for me :-) I know that some Linux based distros ship with something like this but I'm pretty confident I was the first to implement it and someone else idependently came up with the idea.

This is a simple demo application that calls the PAM APIs that an application would call. I use it as a very simple test application, not really useful for anything else.

This is a PAM implementation of the check that /bin/login has hardcoded for root on the system console.

Basically this is a local file that contains usernames and/or netgroups that should either be allowed or denied access to a given service. The idea for this module came from observing the performance hit that the nsswitch passwd_compat +/- syntax can have on some systems. What most people used that for was invalidating the users shell and/or password so they couldn't login, but still allow the admin to get uid->name translations of the files the users owned on the server. This module has appeared in SunSolve articles in the past. I wrote this version of it in 1999.

[Nov 10, 2006] OpenSolaris PAM repository by Darren Moffat

I've just setup the start of a PAM page on as part of the OpenSolaris security community.

I started with some of the PAM modules that I've had sitting in my home directory. I was interesting, for me, to see that I wrote some of these about 9 years ago. I've released these under the CDDL.

If other community members have modules they would like to contribute then send me the code and a description and I'll put them up there.

Note that there is no commitment that these modules will appear in any future release of Solaris or any other OpenSolaris based distro, but there is also nothing stopping distro makers from doing so.

( Apr 27 2006, 03:37:37 PM BST ) Permalink

OpenSolaris Forums/pam_securetty module for OpenSolaris ...

Please review the attached proposal and help with the outstanding issues before I submit this as an ARC case.

Note that the Virtual Console project could end up depending on this case but does not at this time.

Darren J Moffat
In a default Solaris install root is restricted to being able to login only on the /dev/console device.

This functionality can be disabled by commenting out the CONSOLE= variable in /etc/default/login. It can also be changed to give a different device name, however it supports only a single device.

Orthogonally to this root can be made a role and can not login directly at all.

This check is currently implemented in login(1) rather than in a PAM module where it really belongs.

On some Linux and BSD distributions there is PAM module called pam_securetty that implements the check. Even though the module name is the same the configuration file differs between distributions. On NetBSD for example the pam_securetty module looks at /etc/ttys for the secure flag listed against that tty. On CentOS/RedHat Linux
the pam_securetty module uses /etc/securetty which is a per line list of file names relative to /dev that are considered secure.

Problem Area
When OpenSolaris gains Virtual Consoles (PSARC/2006/591) there may be multiple "local" devices that root could login on. Rather than overloading the string "/dev/console" to mean /dev/console and all of the virtual console devices this project proposes removing the check from login(1) and implementing it in a PAM module.

This case proposes the introduction of a pam_securetty(5) module and the removal of the explicity check for CONSOLE= from login(1). The OpenSolaris pam_securetty will perform the CONSOLE= check, so that that interface is preserved. In additon to the CONSOLE= check the module will also check a file named /etc/securetty, if this had been a pure OpenSolaris creation it would probably have been named /etc/security/tty or similar but there seems to be no valid reason
to invent another pathname.

The format of the file will be one device name (relative from /dev) per line, blank lines and those beginning with # are ignored all other lines are assumed to be the name of a device. Paths containing /../ are not allowed and will be skipped.

Since the check is being removed from login(1) the new module needs to be in the PAM account stack for all services that currently use login(1). On upgrade i.pamconf will add the following entry to /etc/pam.conf

other account required

If i.pamconf finds any additional account stacks other than the one for cron it will log a message to the upgrade log to tell the administrator that they need to verify their pam.conf file is correct.

Due to the need to add the additional CONSOLE= check by reading /etc/default/login this module will be implemented from scratch for Solaris rather than using one from LinuxPAM or from a BSD distribution.

Outstanding issues
Is there any impact to Zones ?
Is there any overlap impact with TX ?

New man page for pam_securetty(5)
Updated man page login(1)
vconsole-discuss mailing list
vconsole-discuss at opensolaris dot org

Project details for pam_require

Added: Thu, Feb 27th 2003 13:20 PDT (1 year, 6 months ago)
Updated: Thu, Sep 23rd 2004 00:26 PDT (today)
About: pam_require is a simple Plugable Authentication Module (PAM) for Linux (and maybe other systems which use PAM). It is an account module that allows you to require a special group or user to access a service.

Release focus: Minor bugfixes

Changes: A missing check for primary group membership was added.

Author: Andreas Gohr [contact developer] Secure Cooking with Linux, Part 3

Author's note: PAM (Pluggable Authentication Modules) is a flexible infrastructure for controlling authentication on Linux systems. In this recipe, taken from Chapter 4, "Authentication Techniques and Infrastructures," we show you how to restrict authentication to a given set of users by creating an access control list.

Problem. You would like to apply an access control list (ACL) to an existing service that does not explicitly support ACLs (e.g., telnetd, imapd, etc.).

Solution. Use the listfile PAM module.

First, make sure the server in question uses PAM for authentication, and find out which PAM service name it uses. This may be in the server documentation, or it may be clear from examining the server itself and perusing the contents of /etc/pam.d. For example, suppose you're dealing with the IMAP mail server. First notice that there is a file called /etc/pam.d/imap. Further, the result of:

# locate imapd

shows that the IMAP server is in /usr/sbin/imapd, and:

# ldd /usr/sbin/imapd => /lib/ (0x40027000)

shows that the server is dynamically linked against the PAM library (, also suggesting that it uses PAM. In fact, the Red Hat 8.0 IMAP server uses PAM via that service name and control file ("imap").

Continuing with this example, create an ACL file for the IMAP service, let's say /etc/imapd.acl, and make sure it is not world-writable:

# chmod o-w /etc/imapd.acl

Edit this file, and place in it the usernames of those accounts authorized to use the IMAP server, one name per line. Then, add the following to /etc/pam.d/imap:

account required /lib/security/ file=/etc/imapd.acl \
item=user sense=allow onerr=fail

With this configuration, only those users listed in the ACL file will be allowed access to the IMAP service. If the ACL file is missing, PAM will deny access for all accounts.

Solaris 9 Operating Environment - Features and Benefits Security

The PAM framework has been changed to consist of more modular, smaller shared object files. The PAM API has not been changed. Isolation from naming services is greater.

Specifically, the framework has been enhanced to allow customers to concentrate on developing their own solution without needing to manipulate many of the naming service and authentication details.

Re solaris pam vs. pam for ldap

Our first goal was to install the operating systems and then install openldap to fiddle around and understand how it works. Installing the Solaris OS proved to be quite a challenge in itself as none of us had prior experience working with it. Thus we decided to do a parallel installation and configuration on the Linux platform as well. Much of the documentation on the Internet was done on the Linux platform, thus we can get a comparison between the Solaris and Linux installation and configurations.

On the Linux platform, I used the default RedHat 7.3 distribution with all packages added and then patched them with the up2date program provided by RedHat.The package versions for the main components are as follows:


Instructions for using LDAP server for login authentication using PAM

The references I used to configure the setup can be found here:
Instructions for doing authentication with LDAP
Exploring LDAP -- Part I (Basics), Part II (Directories), Part III (Advanced Topics)

Note: It seems that with RedHat 7.0 onwards you can use authconfig to change the system settings to use LDAP for authentication as well as user information.

Next, we did a check using a network sniffer(Ethereal) and discovered that the passwords were being sent in plain text.(!!!) Thus it was imperative to protect the passwords using some form of encryption. The easiest way to do so seemed to be to protect the transport of the passwords or data with an SSL layer. Fortunately OpenLDAP v2 has built in support for TLS/SSL.

Instructions for enabling TLS/SSL for LDAP server

Upon further testing, we found that Solaris 9 had some problems changing the LDAP passwords on the Linux RH7.3 server with TLS enabled. It works fine the other way. We installed the latest version of Openldap(2.1.3) onto another Solaris 9 server and it works fine there. Solaris 9 now comes with its own version of OpenSSL and LDAP libraries which are TLS enabled.

My notes on installing Openldap on the Solaris 9 server

'I forgot my password!'
When using the PAM to change passwords for LDAP users, it is necessary to have the users' old password. In the event that the user has lost his old password, you will have to modify the LDAP directory directly. Openldap provides a method of doing this with a command called: ldappassword. In general, to change a user's userPassword field in LDAP, use the command shown below. If you omit the -S option, a random password will be generated.

/usr/local/bin/ldappasswd -h -D "cn=yourrootDN,dc=test,dc=org" -w rootDNpasswd -S \

"A line segment that joins the center of a circle with any point on its circumference"
With LDAP up and running, we proceeded to the next part of the project which was to implement a RADIUS server which would connect back to the LDAP backend and use usernames and passwords from the central database. Looking around, we found FreeRadius, which the name implies is free, and supports LDAP as well.

Once configured, we tested the RADIUS server using a Cisco 3500 switch. The Radius protocol provides encryption of the password before sending it onto the network. However we still have to provide encryption between the Radius server and the LDAP server.

Instructions for setting up and configuring FreeRadius Server on Linux

We tested GNU Radius with PAM on Solaris 9 as well. Details can be found here.(courtesy of HoMY)

One calorie breath mint - TicTACACS

The next part of the project was to include TACACS+ to the list of authenticating services available. This was quite straightforward. We obtained the package and followed the instructions found on this site: LDAP support for Tacacs+
It is also possible to get the TACACS+ server to run with PAM. Instructions here:

[Mun Yew] Configure Tac_Plus to use PAM.

Lets do the SAMBA!
Initial attempts to configure Samba (2.2.5) with pam had some drawbacks. We could have either a centralised database in LDAP with the samba schema included BUT require passwd to change the unix password and smbpasswd to change the NT/LM passwords separately, OR let samba have its own database for storing the NT/LM passwords and configure PAM to change both passwords using only passwd. With the latest CVS of Samba (2.2.6pre2), it solved most of the bugs and enabled us to have a unified respository for the passwords and a single method of changing them. Some patches are required to get TLS working in Solaris 9 though. Hopefully it would be included in future releases of Samba.

Instructions on installing and configuring a samba-PDC linked to LDAP backend

No queues for qmail
qmail was the chosen MTA to be used and integrated to use the LDAP username and passwords. Installation of the qmail server was quite straightforward with many websites providing installation and configuration instructions. A checkpassword module which was PAM aware is required.
Details of our installation can be found here. (courtesy of Pat)

A PAtCHy sErver
Apache 2.0.41 and above comes with mod_ldap and mod_auth_ldap modules(currently experimental). However it does require the OpenLDAP SDK (both 1.x and 2.x) or the iPlanet (Netscape) SDK.

Instructions on installing and configuring a Apache 2 with mod_auth_ldap

Links :

Introduction to PAM


Introduction to LDAP
LDAP Implementation HOWTO
Solaris OpenLDAP
NIS+ to LDAP Migration in the SolarisTM 9 Operating Environment [pdf]
[HoMY] Steps to configure OpenLDAP to work
[HoMY] Steps to provide Authentication Services for OpenLDAP

LDAP Implementation HOWTO

LDAP support for Tacacs+
Single-User Network Access Security TACACS+ (by CISCO)
TACACS+ and RADIUS Comparison (by CISCO)


Berkeley Database
Sleepycat Software
[Mun Yew] Berkeley Database 4.0.14 Installation notes

SAMBA (v 2.2) PDC LDAP v.3 howto

Life with qmail


Neohapsis Archives - PAM list - Solaris Pam + Kerberos + OpenSSH - From [email protected]

NETSYS.COM - The Intelligent Hacker's Choice! PAM LDAP Archives pam-list - Re (mod_auth_)pam crashes solaris 8 server

Recommended Links

Google matched content

Softpanorama Recommended

Top articles


Sun blueprints

PAM information and experiences some Solaris information

UW-ID-AUTH Solaris PAM Authentication

The UWdir Identification and Authentication service can be used to provide authentication services to PAM aware applications on the Solaris/Unix platform. This note describes how to obtain and configure an xhier package which will allow Solaris systems to authenticate against the NT4 Domain. A basic configuration allows all PAM aware applications to use the UW/ID-AUTH service; site specific configurations are possible.


PAM (the Pluggable Authentication Module) is a service found in current versions of Solaris (2.6 and later) ager to customize the authentication services that should be used for various applications. The applications (typically login, ftp, dtlogin and other programs that "log a user in") are built to be aware of the services PAM offers -- ie. the program knows how to get PAM to do the authentication. To take advantage of UW/ID-AUTH Solaris PAM Authentication you're going to need:

All PAM implementations rely on the notion of "dynamic linking". The PAM aware application loads the appropriate shared libraries required to do authentication at run time -- it links itself dynamically as required. The PAM library itself is a shared library and it knows how to bring in other shared libraries. The important manual pages to see are pam(3) and pam.conf(4) which describes the configuration file. The configuration file /etc/pam.conf lets the system manager customize the authentication sequence by specifying shared libaries that should be used and how they should be ordered.


Enterprise Linux Magazine

Pluggable authentication modules (PAM) were originally developed by Sun Microsystems and released as an undocumented feature in Solaris 2.3. Since then, Sun has done little with PAM, compared to the open source community, and most specifically, the Linux community. In this article, we will explore the general role of Linux-PAM, its components, configuration and a few general examples of its use.

The Purpose of PAM

The principal purpose of PAM is to provide a framework for authenticating users on a system. To put PAM in perspective, consider the very commonly implemented programs ftp and telnet. Historically, each of these utilities incorporated its own authentication mechanism through its associated daemon: telnetd and ftpd, respectively. Telnetd would use the authentication algorithm supplied by the login program while the ftpd incorporated its own authentication algorithm. These algorithms are quite similar and in most UNIX implementations, ultimately resolved to the use of the entries found in /etc/passwd (and, in some cases, /etc/shadow or similar files). Figure 1 depicts the authentication procedure in this case.

TUCOWS NETWORKWhat the Heck is PAM anyhow? By Kevin Fenzi ([email protected])

Some of your might have noticed mention of PAM in security circles. In this article I will describe how PAM works and demonstrate it's usefulness.

PAM stands for Pluggable Authentication Modules. Basically PAM is a way to change on the fly the way applications or services are authenticated. When you use PAM, you can define at run time how an application or service is authenticated, rather than having to recompile it.

To see why PAM is so usefull, first a bit of UNIX history. Authentication of users was first done using a flat, world readable /etc/passwd file. This file would contain the encrypted password for the user, along with some other information. When a application or service needed to authenticate a user, they would query the user for their password, encrypt it and compare it to the entry in the /etc/passwd file. This worked surprisingly well for a number of years.

Since the /etc/passwd file was readable to everyone (so they could use it to do things like map uids to names and so forth), this meant that encrypted passwords could be examined by others and brute force password crackers could be employed against them. If the user choose a "good" password the cracker would not get anything, but in a large /etc/passwd file, there was always bound to be someone who selected their login name as a password, or "dog" or any easily guessed passwords for the cracker. The first brute force password crackers were simply scripts that would take each word in the dictionary, encrypt them, and test them against each users password entry. Modern ones have gotten a lot more elaborate (checking dictionary names backwards, with numbers and punctuation and the like).

To combat this attack, "shadow" passwords were invented. While most of the user specific information would continue to exist in the /etc/passwd file, the encrypted password and other sensitive data would be moved to an /etc/shadow file that would only be readable by the root user. This made it much harder for crackers to gain access to the encrypted passwords. However, it also meant that all applications that were expecting to authenticate someone had to be modified and re-compiled to look for the password in the /etc/shadow file and not in the /etc/passwd file. By the time this change was starting to gain a lot of acceptance, there were hundreds of applications out there that had to be modified.

A number of systems had also been developed to handle large numbers of users. Typical /etc/passwd files were fine for a few hundred or a few thousand people, but larger unix sites were coming on-line. Replaceing /etc/passwd with a database to cut down lookup times was essential. This required more modification and recompiling of applications.

There are several other schemes for authenticating users that depend on yet other files and servers to communicate with. RADIUS authentication requires you to talk to a RADIUS server. Kerberos requires you to talk to a Kerberos server and so on. All the applications and services that want to authenticate with one of these other servers has to be modified and re-compiled to work with the server they are talking to. This requires modifying all those services and applications again and again.

Pluggable Authentication Modules (PAM) was designed to provide a generic method of accesing a variety of password and other authentication schemes. As the name implies, there is a set of modules which may be "plugged in" to change the behavior of authentication. Effectively, program simply asks PAM "Is this user allowed to access the service I'm offering", and PAM takes care of the background details of searching /etc/shadow, /etc/passwd, checking times, etc...

The "pluggable" means that as your authentication needs change, your software can be adjusted to fit without having to recompile (often a great number of) applications. You simply change the PAM configuration file to reflect the changes in your authentication.

Lets take a look at a PAM configuration file from redhat-6.0. Each service has it's own configuration file. So there is a PAM configuration file for ftp, login, imap, passwd, etc..

This is the /etc/pam.d/rlogin file:

auth       required     /lib/security/
auth       sufficient   /lib/security/
auth       required     /lib/security/ shadow nlok
auth      required     /lib/security/
account    required     /lib/security/
password   required     /lib/security/
password   required     /lib/security/ nullok use_authtok md5 shadow
session    required     /lib/security/

The format of the files in /etc/pam.d/ is:

module-type control-flag module-path arguments

Modules are "stackable", meaning that all the modules are run thru in order. If the "control-flag" is "required" then if any one of them fails, the user is not authenticated.

So, this config for rlogin first runs the module. This checks to see if someone is logging in as root, and if so checks the /etc/securetty file to see if the terminal they are logging in on is "secure". If it's not, then they are rejected.

Next it would run the module. This module checks to see if the user has a ~/.rhosts file that would automaticly grant them access. If so, since it's control-flag is "sufficient", it can grant the user access by itself.

Next the module is called. This is the regular password checking module. It's called with "shadow nullok" so it will also check /etc/shadow files, and if the user had a null password set, it will still allow them access.

Finally in the authentication type modules, is called. If you have a /etc/nologin file, it will show the user the contents of this file and disallow access.

Once a user has logged in, the "account" module(s) are used to record when users log in and out. In this case, the "" module is used which writes the accounting information to syslog and updates /etc/utmp and /etc/wtmp.

The next two lines are for password changing. The first, will check your potential new password against Crack rules to make sure the password you select is a good one. The second will update /etc/passwd and/or /etc/shadow.

Finally, the last line is a "session" type. This allow the module to do anything that the user might need before their session (mounting directories, etc).

You can see that PAM is designed to allow all sorts of modules to authenticate the user to applications or services. Of course, for PAM to be totally useful, all those old programs and services would need to be converted to use PAM. Luckily, the vast majority already have been converted. There are even apache modules for interacting with PAM, as well as python bindings (PyPAM).

Using PAM, you can tailor your authentication to your needs. I would reccomend that you comment out (or remove) the module in all your services files. .rhost files are woefully insecure in these days of spoofing IP addresses.

Another good PAM file to look over and possibly tweak would be the /etc/security/limits.conf. The /etc/security directory contains a number of control files that describe PAM's environment and operations. The limits.conf file shows limits that PAM should put on groups of users when they finish authentication. In this file you can limit the number of processes, amount of memory, and other reaources that users will have available. This is very useful in a public machine that might be subject to "fork bombs" or the like. You can even allow some groups more resources if you so choose.

RedHat 6.0 asks you at install time if you would like to enable MD5 passwords. If you say yes to this option, you will get the ability to have much longer passwords, and likely they will be more secure. Note though, that if you have some application that is shadow aware, but not PAM aware, it will no longer function. Since many applications out there got converted to shadow password files, but not all have been modified to support PAM, you need to be careful when selecting MD5 passwords.

For more information on PAM, see the PAM web page at:


PAM Essentials



Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: July 26, 2020