PAM authentication plugin

Starting in version 5.2.10 (only in the source tarball in 5.2.10), MariaDB includes a PAM authentication plugin. PAM is short for Pluggable Authentication Modules and is an authentication framework used by Linux, FreeBSD, Solaris, and other operating systems.

Usage Examples

PAM makes it possible to implement various authentication scenarios of different complexity. For example,

• authentication using passwords from /etc/shadow (indeed, this is what PAM usually does for a normal shell logins, for pop3, imap, and many other services)
• authentication using LDAP
• authentication using ssh passphrases
• authentication using one-time passwords (even with SMS confirmation!)
• combining different authentication modules, where either one or all of them are required to succeed
• password expiration
• user name mapping
• limiting access by time, date, day of the week, etc.
• logging every login attempt
• and so on, the list is in no way exhaustive.

Installation

This plugin is not loaded by default, you need to install it with

MariaDB [test]> INSTALL PLUGIN pam SONAME 'auth_pam.so';

or by adding --plugin-load=auth_pam.so to the server's command line or to the [mysqld] section in your my.cnf file.

Similar to all other authentication plugins, to create a user in MariaDB which uses PAM authentication, you use

CREATE USER username@hostname IDENTIFIED VIA pam

or, for example,

GRANT SELECT ON db.* TO serg IDENTIFIED VIA pam

Optionally, you can specify a PAM service name, for example:

CREATE USER test_pam IDENTIFIED VIA pam USING 'mariadb_mtr';

This line (copied verbatim from our test suite) creates a user that needs to be authenticated via PAM, using the service name mariadb_mtr.

If no service name is specified, the plugin will use "mysql" as the default PAM service name.

PAM Configuration

The PAM plugin tells MariaDB to delegate the authentication to the PAM subsystem. How exactly the authentication is performed depends on how PAM was configured. Typically, PAM configuration can be found in /etc/pam.d/ or in /etc/pam.conf. The syntax of these configuration files is described in your OS manual, for example, in man pam.d. A minimal example, that we use in our test suite, is

auth            required        pam_mariadb_mtr.so pam_test
account         required        pam_mariadb_mtr.so

This needs to be put in /etc/pam.d/mariadb_mtr — file name must match the name of the PAM service. This simple configuration file instructs the PAM subsystem that for successful authentication it is required that pam_mariadb_mtr.so module (our testing pam module) returns a success. And for an account to be valid, it is required that pam_mariadb_mtr.so module returns a success. You can find many other examples in your /etc/pam.d/ directory.

Note: if you configure PAM to use pam_unix.so and notice that MariaDB needs to run as a root user to be able to access /etc/shadow — try to upgrade your PAM installation. Newer versions of PAM do not require pam_unix.so to be run as root.

Dialog plugin

PAM authentication uses a dialog client plugin to communicate with the user. This allows MariaDB to support arbitrarily complex PAM configurations with regular or one-time passwords, challenge-response, multiple questions, or just about anything else. There is no need to install or enable anything — the dialog plugin is loaded by the client library completely automatically and transparently for the application.

User name mapping

Although PAM modules usually do not do that, PAM may change the user name in the process of authentication. For example, according to the PAM specification, one may start authenticating as John and end up being authenticated as Jim.

The MariaDB PAM authentication plugin fully supports it — the original user name is returned by the SQL function USER(), while the authenticated user name (if changed) is returned by the SQL function CURRENT_USER(), and it is the latter which defines what privileges are available to a connected user.