Gentoo PAM maintenance
1.
Project Description
Pluggable Authentication Method is the main authentication method supported by
Gentoo; the PAM maintenance project maintain the related software.
2.
Developers
| Developer |
Nickname |
Role |
| Diego Elio Pettenò |
flameeyes |
Lead |
| Robin H. Johnson |
robbat2 |
Member ( LDAP- and NSS-related modules ) |
All developers can be reached by e-mail using nickname@gentoo.org.
3.
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 standardised 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's 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.
4.
Resources
Resources offered by the
Gentoo PAM maintenance
project are:
5.
Herds
The Gentoo PAM maintenance
project maintains the following herds:
| Herd |
Members |
Description |
| pam |
flameeyes, robbat2 |
PAM related packages |
|