[MDEV-9150] pam_user_map causes pam unknown user error or segfault Created: 2015-11-18  Updated: 2020-10-20

Status: Open
Project: MariaDB Server
Component/s: Authentication and Privilege System
Affects Version/s: 10.0.22
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Mikael Knutsson Assignee: Elena Stepanova
Resolution: Unresolved Votes: 0
Labels: None
Environment:

OS: Debian GNU/Linux 8.1 (jessie)



 Description   

I've confirmed that without pam_user_map auth_pam works just fine, (ie the user with the same name exists in passwd and in the database.)

We're trying to use pam_user_map with this conf:

/etc/pam.d/mysql:

auth requisite pam_unix.so
account required pam_unix.so
auth required pam_user_map.so

/etc/security/user_map.conf

testuser: dbadmin

The user dbadmin exists in the database with [...] AUTHENTICATED VIA pam set.

Two scenarios can happen. First scenario is if the user dbadmin does not exist in /etc/passwd.
I run mysql -utestuser -p
PAM then logs this:

mysqld: pam_unix(mysql:account): could not identify user (from getpwnam(dbadmin))

The second scenario is if dbadmin actually exists for pam_unix (/etc/passwd), then I get this:

151118 12:24:33 [ERROR] mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 10.0.22-MariaDB-0+deb8u1-log
key_buffer_size=805306368
read_buffer_size=131072
max_used_connections=1
max_threads=502
thread_count=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1888682 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0x7fe1e62ff008
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x7fe3ad585e58 thread_stack 0x80000
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0xbf5afe]
/usr/sbin/mysqld(handle_fatal_signal+0x392)[0x7304d2]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x7fe3aee2b8d0]
/lib/x86_64-linux-gnu/security/pam_user_map.so(+0xbd0)[0x7fe1def9cbd0]
/lib/x86_64-linux-gnu/security/pam_user_map.so(pam_sm_authenticate+0x2dd)[0x7fe1def9cee1]
/lib/x86_64-linux-gnu/libpam.so.0(+0x2f8f)[0x7fe34d9f2f8f]
/lib/x86_64-linux-gnu/libpam.so.0(pam_authenticate+0x2d)[0x7fe34d9f285d]
/usr/lib/mysql/plugin/auth_pam.so(+0xeae)[0x7fe3ad587eae]
/usr/sbin/mysqld[0x550206]
/usr/sbin/mysqld(_Z16acl_authenticateP3THDj+0x104d)[0x5709ad]
/usr/sbin/mysqld[0x6906c6]
/usr/sbin/mysqld(_Z16login_connectionP3THD+0x42)[0x691c82]
/usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x155)[0x692665]
/usr/sbin/mysqld(handle_one_connection+0x39)[0x6927b9]
/usr/sbin/mysqld[0x93c741]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x7fe3aee240a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fe3ada8604d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x0): is an invalid pointer
Connection ID (thread ID): 17
Status: NOT_KILLED

Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on

The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

I did some changes to squash a few implicit warnings I was getting from the compiler as well as the #define PAM_SM_AUTH to make sure PAM allowed it to act as an authentication module.
I'm pasting it below since I'm getting an error from JIRA when I tried to attach it as a patch.

diff --git a/plugin/auth_pam/mapper/pam_user_map.c b/plugin/auth_pam/mapper/pam_user_map.c
index 1c4bccc..535a146 100644
— a/plugin/auth_pam/mapper/pam_user_map.c
+++ b/plugin/auth_pam/mapper/pam_user_map.c
@@ -24,6 +24,8 @@ top: accounting

*/

+#include <string.h>
+#include <ctype.h>
#include <stdlib.h>
#include <stdio.h>
#include <syslog.h>
@@ -31,6 +33,8 @@ top: accounting
#include <pwd.h>

#include <security/pam_modules.h>
+#include <security/pam_ext.h>
+#define PAM_SM_AUTH

#define FILENAME "/etc/security/user_map.conf"
#define skip(what) while (*s && (what)) s++

Some other notes:
I had to get mariadb source for the debian package and compile it from scatch since dialog.so is not installed properly in the Debian packages, I did find a separate issue for this though, but it seems to have stalled.
It would be good to flesh out the documentation regarding this module if you intend to support it, especially with examples of how it will work when it is enabled, much like here:
https://dev.mysql.com/doc/refman/5.5/en/pam-authentication-plugin.html
Which makes it much easier to understand it conceptually.



 Comments   
Comment by Elena Stepanova [ 2015-11-19 ]

Mikael Knutsson,

I think I might be missing something in your setup.
You connect to MariaDB as testuser, do you have this user in the database? Or do you have an anonymous user? Does any of those have proxy on dbadmin, or is configured to use pam?
What I mean is – I don't see from the description how the server can guess to use pam for testuser at all, there is no visible connection between them. Could you please clarify?

Comment by Mikael Knutsson [ 2015-11-20 ]

I've set up an anonymous user with identified via pam The idea with the pam_user_map plugin that is a part of your source tree is that you do the remap of the user before it goes back to the database from PAM, so proxy should not be needed. I also tried with a PROXY grant, but that did not change anything, I'm afraid.

Comment by Geoff Montee (Inactive) [ 2020-10-20 ]

Hi mikn,

I've set up an anonymous user with identified via pam The idea with the pam_user_map plugin that is a part of your source tree is that you do the remap of the user before it goes back to the database from PAM, so proxy should not be needed.

This is incorrect. It is true that the pam_user_map PAM module remaps the user, and then provides the new remapped user name to the database. However, there are two other details that you need to keep in mind:

  • The remapped user also needs to exist in the MariaDB Database.
  • The old user needs to have the PROXY privilege for the remapped user in the MariaDB database.

This is described here: https://mariadb.com/kb/en/user-and-group-mapping-with-pam/#creating-users

And another related detail to keep in mind:

  • The remapped user needs to exist in the PAM authentication system as well (e.g. in your case, you use pam_unix, so the user would need to exist in /etc/shadow) .

This is described here: https://mariadb.com/kb/en/user-and-group-mapping-with-pam/#pam-user-with-same-name-as-mapped-mariadb-user-must-exist

I also tried with a PROXY grant, but that did not change anything, I'm afraid.

The version of pam_user_map from the MariaDB 10.0.22 source distribution has not been updated in 8 years, so I suspect that it has a lot of old bugs:

https://github.com/MariaDB/server/blob/mariadb-10.0.22/plugin/auth_pam/mapper/pam_user_map.c

Compare this version to the version in MariaDB 10.5.6:

https://github.com/MariaDB/server/blob/mariadb-10.5.6/plugin/auth_pam/mapper/pam_user_map.c

I would suggest trying a more recent version of pam_user_map to determine if that fixes the crashes.

Also, I should mention that if you upgrade to MariaDB 10.4 or later, then PAM crashes won't crash the whole server. See MDEV-15473 for details. I would definitely recommend upgrading, since MariaDB 10.0 is EOL.

Generated at Thu Feb 08 07:32:30 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.