This is Gentoo's testing wiki. It is a non-operational environment and its textual content is outdated.
Please visit our production wiki at https://wiki.gentoo.org
Project:PAM
| Pluggable Authentication Method maintenance | |
|---|---|
| Description | Pluggable Authentication Method is the main authentication method supported by Gentoo; the PAM maintenance project maintain the related software. |
| Project email | pam-bugs@gentoo.org |
| Lead(s) | none No lead election date set |
| Member(s) |
|
| Subproject(s) (and inherited member(s)) |
(none) |
| Parent Project | Gentoo Base System |
| Project listing | |
Pluggable Authentication Method is the main authentication method supported by Gentoo; the PAM maintenance project maintain the related software.
What is PAM
PAM stands for Pluggable Authentication Modules, and refers to a framework for wrapping various low-level authentication methods and facilities in a single, mostly standardized API, originally designed and implemented by Sun Microsystems and, as of today, common for Linux distributions and other Unix and Unix-like operating systems (FreeBSD, NetBSD, Solaris, Apple Mac OS X, IBM AIX, HP-UX, etc.).
PAM is a very flexible framework, allowing a wide range of different setups to be implemented, without having to add extra support in all the software that needs authentication capabilities. For instance, it's possible to get Dovecot (an IMAP server) to authenticate transparently against MySQL, PostgreSQL, LDAP, or system users, without having to add any specific code for that to Dovecot itself (on the other hand, Dovecot does implement specific code to authenticate users against various SQL databases, but that is another story).
The drawback of such a flexible framework is that the system is quite complex and fragile, as there are three or four different pieces of software that are involved in authentication. For this reason, there are applications that even when providing PAM authentication support, also provide (or even prefer) alternative solutions, like specific authentication code for various databases and file formats, or even their own plug-ins for different authentication methods.
As I said, there are three or four different pieces of software involved in authentication using PAM: the application authenticating (like Dovecot in the previous example), the libpam library (from now on the PAM implementation ), the PAM module (that might or might not be distributed with the PAM implementation), and eventually a backend service like an SQL database, LDAP or some other library used by the module.
You can probably already understand that when we talk about the PAM implementation, we refer about one implementation of the PAM framework, that is not unique. There are, indeed, multiple PAM implementations: other than the proprietary ones provided by various operating systems, there are at least two main Free Software implementations, Linux-PAM (not to be fooled by the name, as this was used by FreeBSD 4.0, and still is used by Apple Mac OS X) released under double GPL-2/BSD-3 license, and OpenPAM, developed for NetBSD, but also used by FreeBSD since 5.0 and (for a while at least) by ALTlinux.
Albeit the two implementations are mostly API compatible (Linux-PAM provides some extra utility functions in a libpam_misc library), and at least in part ABI compatible, there are other differences too: Linux-PAM provides a set of default PAM modules, while OpenPAM does not provide but the two main modules (pam_permit and pam_deny). For this reason, OpenPAM requires at a minimum an extra software component: the modules themselves.
Beside the default set of modules (if provided), there are a few extra modules to add support for authentication against software like MySQL, PostgreSQL, LDAP, and similar. These modules are the main flexibility feature of PAM framework, as it is possible to create modules to authenticate in new ways without redesigning the whole authentication support in the applications (like for instance smartcard or USB token authentication), for local services at least.
Most of the modules, then, don't take care of authentication by themselves, but rely on backend software, either being a backend service like a database or LDAP server, or a library (like BDB). This increase complexity once again, as a bug, a regression or a file format change for such a service might break authentication for all the services configured to make use of it. This is for instance the case for BDB-based authentication: if the module changed the version of the library it links against, the old authentication database would be unusable.
For further documentation about the maintenance of PAM packages, the handling of PAM-compatible packages in ebuilds, and the administration of PAM authentication, please refer to the resources offered by this project page.
Resources
Resources offered by the Gentoo PAM maintenance project include:
This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Diego Elio Pettenò (Flameeyes)
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.