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.
MariaDB [test]> INSTALL PLUGIN pam SONAME 'auth_pam.so';
CREATE USER username@hostname IDENTIFIED VIA pam
GRANT SELECT ON db.* TO serg IDENTIFIED VIA pam
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.
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
module returns a success. You can find many other examples in your
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.
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.