Details
-
Task
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
None
-
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…
Attachments
Issue Links
- blocks
-
MDEV-15473 Isolate/sandbox PAM modules, so that they can't crash the server
-
- Closed
-
- causes
-
MDEV-19876 pam v2: auth_pam_tool_dir and auth_pam_tool permissions are wrong in RPMs
-
- Closed
-
-
MDEV-19877 pam v2: auth_pam_tool input format is not user friendly for debugging
-
- Open
-
-
MDEV-19878 pam v2: pam password authentication doesn't work at all
-
- Closed
-
-
MDEV-19880 pam v1: pam password authentication doesn't work at all in MariaDB 10.4
-
- Closed
-
-
MDEV-19881 pam plugin from MariaDB 10.3 doesn't work with MariaDB 10.4
-
- Open
-
-
MDEV-19882 pam v2: auth_pam_tool truncates passwords that are not null-terminated
-
- Closed
-
-
MDEV-21385 PAM v2 plugin produces lots of zombie processes
-
- Closed
-
-
MDEV-22459 pam v2 should log an error if auth_pam_tool exec fails
-
- Closed
-
-
MDEV-22482 pam v2: mysql_upgrade doesn't fix the ownership/privileges of auth_pam_tool
-
- Open
-
-
MXS-2633 Pam authentication doesn't work with server 10.4
-
- Closed
-
- includes
-
MDEV-14838 PAM authentication requires mysql user to be in the shadow group
-
- Closed
-
- relates to
-
MDEV-16813 Document PAM updates
-
- Open
-
-
MDEV-18311 Change default PAM service name to mariadb
-
- Open
-
-
MXS-3753 Add option to run PAM authentication in a suid sanbox
-
- Closed
-
> 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 ...)