MariaDB PAM Mapping: One Password, Several Identity Boundaries
Delegating MariaDB authentication to PAM can remove a separate database password from the workflow. It also introduces several identities that must agree: the Unix account, the PAM service and policy, the mapped MariaDB account, and the database grants attached to that account. A successful password check is only the first part of authorization.
PAM authenticates; MariaDB still authorizes
MariaDB's PAM authentication plugin hands credential verification to the host's Pluggable Authentication Module stack. The database account still must exist and have privileges. The documentation makes this separation clear: PAM answers an authentication question, while MariaDB evaluates account privileges after the connection is associated with a principal.
The mapping layer matters when the Unix name does not match the database account. MariaDB documents pam_user_map for mapping Unix users and groups to MariaDB users. In one documented pattern, a Unix user foo maps to database user bar, and members of the Unix group dba map to the database user dba. The mapping file expresses rules such as foo: bar and @dba:dba.
That mapping can be convenient, but it concentrates authority. Adding a person to a Unix group can change which database account they reach. Removing them from the group may not invalidate an existing database session. A local account with the mapped database name may also need to exist so PAM can complete its checks, as the MariaDB walkthrough explains.
Review all four layers
Start with the PAM service definition. Identify which modules run for authentication and account checks, where logs go, and whether the service permits local or centralized identities. Then inspect /etc/security/user_map.conf or the configured mapping file. Confirm the mapping order and whether a broad group rule overrides a narrow user rule.
Next, list the MariaDB accounts that use the pam plugin and their host patterns. Map each to roles and grants. Remove accounts that are no longer tied to a current Unix identity. Finally, review the application connection string and host. PAM authentication does not make the unix_socket plugin redundant, and the two plugins have different trust assumptions. Unix socket authentication is intended for local socket connections and should not be treated as a remote access method.
Test change and removal
Test with a user who is in the mapped group, a user who has been removed, and a user with a similarly named account. Confirm that an existing session is closed when the access decision changes, or document the operational delay. Check that failed PAM account checks do not fall through to another authentication plugin for the same account.
Log successful MariaDB connections with the original client identity, mapped database account, host, and timestamp. Alert on mapping changes and on group membership changes for privileged maps. Preserve the PAM configuration with source control where the platform allows it, and review patches that alter the PAM stack.
The design can be strong when the mapping is narrow and the group lifecycle is controlled. Problems appear when a broad Unix group becomes an implicit database role or when an old mapping remains after an employee or service changes owners.
Top comments (0)