Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
When a MariaDB plug-in was added to the server.cnf or my.cnf files and the user was created to authenticate using Pluggable Authentication Module (PAM) in the mysqld service, the plug-in could not be loaded. To fix this bug, SELinux policy rules have been updated, and the plugin is now loaded successfully.
+++ This bug was initially created as a clone of Bug #1196104 +++
<snip>
--- Additional comment from Honza Horak on 2015-03-12 12:16:03 EDT ---
These are my steps to reproduce:
#> cat >/etc/pam.d/mysql <<EOF
auth required pam_unix.so
account required pam_unix.so
EOF
#> echo 'testusr:$6$ThDum2kp$Qkwr/72qEalUsqCdM.SsjbJJnnX7OCxHnMgjEhAq4rTmeXwXW0dLWxDcCkoVRS8GyNZgIHtaEReJaUK4hdNMV/:13306:13306::/home/testusr:/bin/bash' >>/etc/passwd
#> systemctl start mariadb
MariaDB [(none)]> install plugin pam soname 'auth_pam.so';
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> create user testusr@localhost identified via pam;
Query OK, 0 rows affected (0.00 sec)
#> mysql -u testusr -pabcdef
This works with SELinux in permissive mode, but there are the following AVCs (some seen only after 'dontaudit' disabled):
type=AVC msg=audit(1426177678.046:2639): avc: denied { create } for pid=8591 comm="mysqld" scontext=unconfined_u:system_r:mysqld_t:s0 tcontext=unconfined_u:system_r:mysqld_t:s0 tclass=netlink_audit_socket
type=AVC msg=audit(1426177678.046:2640): avc: denied { write } for pid=8591 comm="mysqld" scontext=unconfined_u:system_r:mysqld_t:s0 tcontext=unconfined_u:system_r:mysqld_t:s0 tclass=netlink_audit_socket
type=AVC msg=audit(1426177678.046:2640): avc: denied { nlmsg_relay } for pid=8591 comm="mysqld" scontext=unconfined_u:system_r:mysqld_t:s0 tcontext=unconfined_u:system_r:mysqld_t:s0 tclass=netlink_audit_socket
type=AVC msg=audit(1426177678.046:2641): avc: denied { read } for pid=8591 comm="mysqld" scontext=unconfined_u:system_r:mysqld_t:s0 tcontext=unconfined_u:system_r:mysqld_t:s0 tclass=netlink_audit_socket
(In reply to Honza Horak from comment #0)
<snip>
The reproducer actually should use the mariadb collection and service call:
> #> systemctl start mariadb
#> service rh-mariadb100-mariadb start
> #> mysql -u testusr -pabcdef
#> scl enable rh-mariadb100 -- mysql -u testusr -pabcdef
I'm also not sure if these SELinux issues are caused by communication with pam and thus will be visible with *every pam plugin* or they are *specific for pam_unix.so* module. In the later case it seems the SELinux would need to be created for every module specifically for used pam module, right?
We also have an issue that possible fix won't be available in selinux-policy soon enough -- so I'm wondering what are our options regarding fixing this directly in rh-mariadb100-mariadb package?
There is a bit simpler reproducer that uses pam_permit.so module, so there shouldn't be any AVCs specific to pam_unix.so:
1. install rh-mariadb100 collection from upcoming RHSCL-2.0
#> yum install rh-mariadb100
2. create pam configuration
#> cat >/etc/pam.d/mysql <<EOF
auth required pam_permit.so
account required pam_permit.so
EOF
3. start the daemon
#> service rh-mariadb100-mariadb start
4. install the plugin
MariaDB [(none)]> install plugin pam soname 'auth_pam.so';
Query OK, 0 rows affected (0.00 sec)
5. create a user that identifies by pam
MariaDB [(none)]> create user testusr@localhost identified via pam;
Query OK, 0 rows affected (0.00 sec)
6. try to log in with this user
#> scl enable rh-mariadb100 -- mysql -u testusr -pabcdef
Current results:
ERROR 1045 (28000): Access denied for user 'testusr'@'localhost' (using password: NO)
Expected results:
login works
Additional info:
I got the following AVCs with the steps above:
type=AVC msg=audit(1426232392.662:3348): avc: denied { create } for pid=11334 comm="mysqld" scontext=unconfined_u:system_r:mysqld_t:s0 tcontext=unconfined_u:system_r:mysqld_t:s0 tclass=netlink_audit_socket
type=AVC msg=audit(1426232392.662:3349): avc: denied { create } for pid=11334 comm="mysqld" scontext=unconfined_u:system_r:mysqld_t:s0 tcontext=unconfined_u:system_r:mysqld_t:s0 tclass=netlink_audit_socket
However, I'm still not sure if this is something we should fix in either selinux-policy or mariadb package or it is just a specific configuration and user needs to create own specific SELinux rules for that. Which one is the correct way?
(In reply to Honza Horak from comment #1)
> It's weird that this works fine with RHEL-7 but it doesn't on F21.
Hm, now it doesn't seem so, probably just wrong testing, now I see the same issue in RHEL-7 as well.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHBA-2015-1375.html