Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-17315

When using group mapping from pam_user_map module, a system user account with the mapped name needs to exist

    XMLWordPrintable

    Details

      Description

      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.

      https://github.com/MariaDB/server/blob/54caaf684801c332a7130d478023aa7706a69aa1/plugin/auth_pam/auth_pam.c#L154

      https://linux.die.net/man/3/pam_authenticate

      • 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.

      https://github.com/MariaDB/server/blob/54caaf684801c332a7130d478023aa7706a69aa1/plugin/auth_pam/auth_pam.c#L157

      https://linux.die.net/man/3/pam_acct_mgmt

      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.

      https://github.com/MariaDB/server/blob/2ad51a0bd8380fba3d03a4cebd43860329b7fbaa/plugin/auth_pam/mapper/pam_user_map.c#L135

      https://linux.die.net/man/3/pam_sm_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:

      #%PAM-1.0
      auth required pam_sss.so
      account sufficient pam_unix.so
      account sufficient pam_sss.so
      auth required pam_user_map.so debug
      

      And /etc/security/user_map.conf looks like this:

      @dba: dba
      

      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:

      Sep 27 17:17:05 dbserver1 mysqld: pam_user_map(mysql:auth): Opening file '/etc/security/user_map.conf'.
      Sep 27 17:17:05 dbserver1 mysqld: pam_user_map(mysql:auth): Incoming username 'alice'.
      Sep 27 17:17:05 dbserver1 mysqld: pam_user_map(mysql:auth): User belongs to 4 groups [dba,mongod,mongodba,mysql].
      Sep 27 17:17:05 dbserver1 mysqld: pam_user_map(mysql:auth): Check if user is in group 'mysql': YES
      Sep 27 17:17:05 dbserver1 mysqld: pam_user_map(mysql:auth): User mapped as 'dba'
      Sep 27 17:17:05 dbserver1 mysqld: pam_unix(mysql:account): could not identify user (from getpwnam(dba))
      Sep 27 17:17:05 dbserver1 mysqld: pam_sss(mysql:account): Access denied for user dba: 10 (User not known to the underlying authentication module)
      Sep 27 17:17:05 dbserver1 mysqld: 2018-09-27 17:17:05 72 [Warning] Access denied for user 'alice'@'localhost' (using password: NO)
      

      This can be solved by simply adding a system user with the same name as the group being mapped:

      useradd dba -g dba
      

      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.

      https://linux.die.net/man/3/pam_sm_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.

      https://github.com/MariaDB/server/blob/2ad51a0bd8380fba3d03a4cebd43860329b7fbaa/plugin/auth_pam/mapper/pam_user_map.c#L220

      https://linux.die.net/man/3/pam_set_item

      However, I don't know enough about PAM to know for sure that this would make the problem go away.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned
              Reporter:
              GeoffMontee Geoff Montee
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Git Integration