Hide Forgot
Description of problem: MySQL resource agent produces an AVC denial when attempting to create a PID file at /run/mysql/mysqld.pid which results in cluster service that's unable to start. Version-Release number of selected component (if applicable): selinux-policy-3.13.1-99.el7.noarch selinux-policy-targeted-3.13.1-99.el7.noarch resource-agents-3.9.5-81.el7.x86_64 How reproducible: always Steps to Reproduce: 1. have a cluster with ocf::heartbeat:mysql service configured 2. cluster is unable to start the service: > * mysql_start_0 on virt-297 'unknown error' (1): call=36, status=complete, exitreason='MySQL server failed to start (pid=21794) (rc=0), please check your installation', > last-rc-change='Mon Sep 19 15:53:49 2016', queued=0ms, exec=2413ms Actual results: AVC denial, service unable to start in enforcing mode Expected results: no AVC denials, mysqld starts and cluster monitor action succeeds Additional info: (with enforcing mode) > type=SYSCALL msg=audit(09/19/16 15:53:50.693:1825) : arch=x86_64 syscall=open success=no exit=EACCES(Permission denied) a0=0x7f42dc0ba5a0 a1=O_WRONLY|O_CREAT|O_TRUNC a2=0664 a3=0x8 items=0 ppid=21794 pid=22017 auid=unset uid=mysql gid=mysql euid=mysql suid=mysql fsuid=mysql egid=mysql sgid=mysql fsgid=mysql tty=(none) ses=unset comm=mysqld exe=/usr/libexec/mysqld subj=system_u:system_r:mysqld_t:s0 key=(null) > type=AVC msg=audit(09/19/16 15:53:50.693:1825) : avc: denied { write } for pid=22017 comm=mysqld name=mysql dev="tmpfs" ino=62135 scontext=system_u:system_r:mysqld_t:s0 tcontext=system_u:object_r:cluster_var_run_t:s0 tclass=dir (with permissive mode) > type=SYSCALL msg=audit(09/19/16 15:42:43.126:1559) : arch=x86_64 syscall=open success=yes exit=16 a0=0x7f45f19d95a0 a1=O_WRONLY|O_CREAT|O_TRUNC a2=0664 a3=0x8 items=0 ppid=18855 pid=19072 auid=unset uid=mysql gid=mysql euid=mysql suid=mysql fsuid=mysql egid=mysql sgid=mysql fsgid=mysql tty=(none) ses=unset comm=mysqld exe=/usr/libexec/mysqld subj=system_u:system_r:mysqld_t:s0 key=(null) > type=AVC msg=audit(09/19/16 15:42:43.126:1559) : avc: denied { write } for pid=19072 comm=mysqld path=/run/mysql/mysqld.pid dev="tmpfs" ino=194715 scontext=system_u:system_r:mysqld_t:s0 tcontext=system_u:object_r:cluster_var_run_t:s0 tclass=file > type=AVC msg=audit(09/19/16 15:42:43.126:1559) : avc: denied { create } for pid=19072 comm=mysqld name=mysqld.pid scontext=system_u:system_r:mysqld_t:s0 tcontext=system_u:object_r:cluster_var_run_t:s0 tclass=file > type=AVC msg=audit(09/19/16 15:42:43.126:1559) : avc: denied { add_name } for pid=19072 comm=mysqld name=mysqld.pid scontext=system_u:system_r:mysqld_t:s0 tcontext=system_u:object_r:cluster_var_run_t:s0 tclass=dir > type=AVC msg=audit(09/19/16 15:42:43.126:1559) : avc: denied { write } for pid=19072 comm=mysqld name=mysql dev="tmpfs" ino=62135 scontext=system_u:system_r:mysqld_t:s0 tcontext=system_u:object_r:cluster_var_run_t:s0 tclass=dir > ---- > type=SYSCALL msg=audit(09/19/16 15:42:58.964:1607) : arch=x86_64 syscall=unlink success=yes exit=0 a0=0x7f45f19d95a0 a1=0x0 a2=0x7f45f19d95a0 a3=0x7f45f3834cec items=0 ppid=18855 pid=19461 auid=unset uid=mysql gid=mysql euid=mysql suid=mysql fsuid=mysql egid=mysql sgid=mysql fsgid=mysql tty=(none) ses=unset comm=mysqld exe=/usr/libexec/mysqld subj=system_u:system_r:mysqld_t:s0 key=(null) > type=AVC msg=audit(09/19/16 15:42:58.964:1607) : avc: denied { unlink } for pid=19461 comm=mysqld name=mysqld.pid dev="tmpfs" ino=194715 scontext=system_u:system_r:mysqld_t:s0 tcontext=system_u:object_r:cluster_var_run_t:s0 tclass=file > type=AVC msg=audit(09/19/16 15:42:58.964:1607) : avc: denied { remove_name } for pid=19461 comm=mysqld name=mysqld.pid dev="tmpfs" ino=194715 scontext=system_u:system_r:mysqld_t:s0 tcontext=system_u:object_r:cluster_var_run_t:s0 tclass=dir
Is the /run/mysql directory local or is it mounted from another machine?
It's local (/var is a tmpfs mount).
Sorry, /run is a tmpfs mount, not /var.
*** Bug 1379355 has been marked as a duplicate of this bug. ***
Hi, Are you still able to reproduce the issue? THanks, Lukas.
Created attachment 1485928 [details] force/restore correct SELinux right for /var/run/mysql in cluster context (resource-agents) Hoping I'm not chasing the wrong bug, I think I might have a clue on the cause (regression) and resolution: I encountered the same bug which triggers only when those 3 conditions exist: - cluster - SELinux enabled - mariadb Appeared first in RHEL 7.3 as far as I can remember. I resolved it more than a year ago with this simple attached patch, which I reapply successfully for each RHEL 7 minor version upgrade (more specifically for each resource-agents package upgrade). I never got to file a bug report about it, but when finally deciding to file a bug, I saw this bug which I think appears to be the same. The directory /var/run/mysql (really /run/mysql ) when first created since RHEL 7.3 looks like this: drwxr-x--x. mysql mysql system_u:object_r:cluster_var_run_t:s0 /var/run/mysql The patch just runs restorecon to make it look like this: drwxr-x--x. mysql mysql system_u:object_r:var_run_t:s0 /var/run/mysql Enabling the creation of /var/run/mysql/mysqld.pid -rw-rw----. mysql mysql system_u:object_r:mysqld_var_run_t:s0 /var/run/mysql/mysqld.pid Basically the patch just runs "restorecon /var/run/mysql". I believe the regression was introduced with the resolution of bug rhbz#1346900
Ok I'm just seeing I didn't look at the bug report dates. I might have to file a new bug report instead. Considering the dates, this might not be the same bug (even if happening at the same place).
Confirmed that this is still a bug on RHEL 7.6 with resource-agents 4.1.1-12.el7_6.4 A sign that you have hit this bug is when you set up the mysql resource agent on pacemaker and upon starting the resource you see in /var/log/mysqld.log: [ERROR] Can't start server: can't create PID file: Permission denied [ERROR] /usr/sbin/mysqld: Can't create/write to file '/var/run/mysql/mysqld.pid' (Errcode: 13 - Permission denied)
*** Bug 1636012 has been marked as a duplicate of this bug. ***
This issue was not selected to be included in Red Hat Enterprise Linux 7.7 because it is seen either as low or moderate impact to a small number of use-cases. The next release will be in Maintenance Support 1 Phase, which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available. We will now close this issue, but if you believe that it qualifies for the Maintenance Support 1 Phase, please re-open; otherwise, we recommend moving the request to Red Hat Enterprise Linux 8 if applicable.