The authentication process used by MariaDB's PAM authentication plugin goes like this:
- First, it calls pam_authenticate. This step causes the server to authenticate the user account by evaluating all auth module types in the provided PAM service configuration.
- Second, it calls pam_acct_mgmt. This step causes the server to verify the user account by evaluating all *account* module types in the provided PAM service configuration.
This process is complicated somewhat when the pam_user_map module is included in the PAM service configuration. The pam_user_map module calls pam_sm_authenticate, which means that it is a auth module type, and it is evaluated when the plugin calls pam_authenticate.
When group mapping is used along with pam_user_map, this means that the user being verified during the pam_acct_mgmt step is not the original user. If a user account with the same name does not exist, this can cause problems.
To give a concrete example, let's say that you have the following PAM service configuration:
And /etc/security/user_map.conf looks like this:
If no system user called "dba" exists, then authentication will fail during the pam_acct_mgmt step, and the syslog will have messages like this:
This can be solved by simply adding a system user with the same name as the group being mapped:
But I wonder whether this limitation can be lifted, and if so, whether we would want to lift it. One possible solution would be to implement pam_sm_acct_mgmt for pam_user_map, so that group mapping could optionally happen as a account module type, rather than an auth module type, and it would be evaluated when the plugin called pam_acct_mgmt.
I see that the user is actually changed with pam_set_item, and it looks like that can be called from any module type.
However, I don't know enough about PAM to know for sure that this would make the problem go away.