[MDEV-7032] new pam plugin with a suid wrapper Created: 2014-11-06  Updated: 2021-09-01  Resolved: 2018-07-03

Status: Closed
Project: MariaDB Server
Component/s: Plugin - pam
Fix Version/s: 10.4.0

Type: Task Priority: Critical
Reporter: Sergei Golubchik Assignee: Alexey Botchkov
Resolution: Fixed Votes: 3
Labels: None

Issue Links:
Blocks
blocks MDEV-15473 Isolate/sandbox PAM modules, so that ... Closed
PartOf
includes MDEV-14838 PAM authentication requires mysql use... Closed
Problem/Incident
causes MDEV-19876 pam v2: auth_pam_tool_dir and auth_pa... Closed
causes MDEV-19877 pam v2: auth_pam_tool input format is... Open
causes MDEV-19878 pam v2: pam password authentication d... Closed
causes MDEV-19880 pam v1: pam password authentication d... Closed
causes MDEV-19881 pam plugin from MariaDB 10.3 doesn't ... Open
causes MDEV-19882 pam v2: auth_pam_tool truncates passw... Closed
causes MDEV-21385 PAM v2 plugin produces lots of zombie... Closed
causes MDEV-22459 pam v2 should log an error if auth_pa... Closed
causes MDEV-22482 pam v2: mysql_upgrade doesn't fix the... Open
causes MXS-2633 Pam authentication doesn't work with ... Closed
Relates
relates to MDEV-16813 Document PAM updates Open
relates to MDEV-18311 Change default PAM service name to ma... Open
relates to MXS-3753 Add option to run PAM authentication ... Closed
Sprint: 10.4.0-1

 Description   

PAM authentication in many cases only works if done by the root user or the user that is authenticating itself.

For example, to read /etc/shadow one has to be root. unix_chkpwd wrapper, created specifically to loosen this requirement, checks that user name matches the current UID. Google-authenticator PAM module reads the data from ~user/ home directory — again, can be only done as root or that user. And so on.

A solution to all these problems could be a small setuid wrapper that pam plugin invokes. Perhaps this wrapper should check that it is invoked as mysql user…

 Comments   
Comment by Hartmut Holzgraefe [ 2014-11-06 ]

> Perhaps this wrapper should check that it is invoked as mysql user…

This is an absolute must requirement IMHO to not expose /etc/shadow password information to a random user
(it is the reason for the UID checks within unix_chkpwd in the first place)

But all in all I think that pam_unix doesn't work as a general authentication mechanism by design and that no new tools to work around this should be distributed ...

If /etc/shadow based authentication is a must then explicitly adding user "mysql" the "shadow" group looks like a better approach as it requires explicit admin action ... problem right now though is that this automatically exposes
shadow contents to LOAD DATA INFILE. MySQL manual states that LOAD DATA INFILE can only read world-readable local files, but this seems to be a mixup - I can only find a check for that in the LOAD_FILE() function implementation which is a totally different beast than LOAD DATA INFILE ... (documentation bug report about that about to be written ...)

Comment by Sergei Golubchik [ 2014-11-08 ]

/etc/shadow is just one use case. S/Key stores data in /etc/skeykeys. I've got complains about google-authenticator too. Many other PAM modules store data in $HOME. This setuid wrapper is the only solution I can think of that solves all these issues.

Comment by Alexey Botchkov [ 2018-07-03 ]

Fixed along with the MDEV-15473

Comment by Christopher Halbersma [ 2018-07-09 ]

> Fixed along with the MDEV-15473

Nice.

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