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.

Bug 1377383

Summary: [resource-agents] MySQL resource agent PID file creation fails
Product: Red Hat Enterprise Linux 7 Reporter: Patrik Hagara <phagara>
Component: selinux-policyAssignee: Lukas Vrabec <lvrabec>
Status: CLOSED WONTFIX QA Contact: Milos Malik <mmalik>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.3CC: belhouane.adel, jvandyk, lvrabec, mgrepl, mlisik, mmalik, mnovacek, phagara, plautrba, pvrabec, ssekidde, zpytela
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-02-28 19:14:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
force/restore correct SELinux right for /var/run/mysql in cluster context (resource-agents) none

Description Patrik Hagara 2016-09-19 14:22:04 UTC 
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
Comment 3 Milos Malik 2016-09-20 09:57:38 UTC 
Is the /run/mysql directory local or is it mounted from another machine?
Comment 4 Patrik Hagara 2016-09-20 11:11:01 UTC 
It's local (/var is a tmpfs mount).
Comment 5 Patrik Hagara 2016-09-20 11:11:47 UTC 
Sorry, /run is a tmpfs mount, not /var.
Comment 9 Lukas Vrabec 2016-09-26 16:46:39 UTC 
*** Bug 1379355 has been marked as a duplicate of this bug. ***
Comment 12 Lukas Vrabec 2018-06-11 08:40:01 UTC 
Hi, 

Are you still able to reproduce the issue? 

THanks,
Lukas.
Comment 14 Adel Belhouane 2018-09-22 12:55:33 UTC 
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
Comment 15 Adel Belhouane 2018-09-22 13:12:46 UTC 
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).
Comment 16 jvandyk 2018-11-01 18:49:31 UTC 
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)
Comment 17 Lukas Vrabec 2018-11-08 14:41:33 UTC 
*** Bug 1636012 has been marked as a duplicate of this bug. ***
Comment 18 Zdenek Pytela 2019-02-28 19:14:05 UTC 
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.