Bug 985442 - Please create (working) policy for pacemaker
Please create (working) policy for pacemaker
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy (Show other bugs)
6.4
All Linux
urgent Severity urgent
: rc
: ---
Assigned To: Miroslav Grepl
Milos Malik
: ZStream
Depends On: 915151
Blocks: 1021635
  Show dependency treegraph
 
Reported: 2013-07-17 09:43 EDT by Jan Kurik
Modified: 2013-11-01 09:47 EDT (History)
17 users (show)

See Also:
Fixed In Version: selinux-policy-3.7.19-195.el6_4.16
Doc Type: Bug Fix
Doc Text:
Previously, the pacemaker resource manager did not have its own policy defined and started in the initrc_t domain. With this update, the wrong context has been fixed and proper permissions have been set for pacemaker, thus fixing the bug.
Story Points: ---
Clone Of:
: 1021635 (view as bug list)
Environment:
Last Closed: 2013-11-01 09:47:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Kurik 2013-07-17 09:43:05 EDT
This bug has been copied from bug #915151 and has been proposed
to be backported to 6.4 z-stream (EUS).
Comment 11 Jaroslav Kortus 2013-07-25 05:04:59 EDT
commented in https://bugzilla.redhat.com/show_bug.cgi?id=915151#c38.

I'd like to have only comments related to 6.4.z version here after it's ready. I'll comment 6.5 in the parent bug 915151.
Comment 27 Miroslav Grepl 2013-10-21 12:28:32 EDT
It looks there is a pacemaker bug. How is /var/lib/pacemaker created? Is it a part of rpm payload? 

# ls -dZ /var/lib/pacemaker/
drwxr-x---. hacluster haclient system_u:object_r:var_lib_t:s0   /var/lib/pacemaker/
# matchpathcon /var/lib/pacemaker
/var/lib/pacemaker	system_u:object_r:cluster_var_lib_t:s0

So I believe we are done with pacemaker+SELinux and it needs to be fixed in the pacemaker pkg (rgmanager is a different issue).
Comment 29 Jaroslav Kortus 2013-10-21 12:41:06 EDT
(In reply to Miroslav Grepl from comment #27)
> It looks there is a pacemaker bug. How is /var/lib/pacemaker created? Is it
> a part of rpm payload? 
> 
> # ls -dZ /var/lib/pacemaker/
> drwxr-x---. hacluster haclient system_u:object_r:var_lib_t:s0  
> /var/lib/pacemaker/
> # matchpathcon /var/lib/pacemaker
> /var/lib/pacemaker	system_u:object_r:cluster_var_lib_t:s0
> 
> So I believe we are done with pacemaker+SELinux and it needs to be fixed in
> the pacemaker pkg (rgmanager is a different issue).

Can you please elaborate on how this should be fixed? Maybe the devs know, but I'd like to have it here to speed things up.

Diky,
J.
Comment 30 Miroslav Grepl 2013-10-21 12:47:32 EDT
Well I believe pacemaker devs know how this directory is created which we need to know to fix it. Either restorecon will be needed or it should be created in the payload.
Comment 31 Miroslav Grepl 2013-10-21 12:52:52 EDT
Who does /var/run/cluster/fence_scsi* create?
Comment 33 Fabio Massimo Di Nitto 2013-10-21 13:16:29 EDT
(In reply to Miroslav Grepl from comment #30)
> Well I believe pacemaker devs know how this directory is created which we
> need to know to fix it. Either restorecon will be needed or it should be
> created in the payload.

[fabbione@lilith rhel]$ rpm -q -p pacemaker-1.1.10-1.el6_4.4.x86_64.rpm -l |grep var/lib
/var/lib/pacemaker
/var/lib/pacemaker/blackbox
/var/lib/pacemaker/cib
/var/lib/pacemaker/cores
/var/lib/pacemaker/pengine

it's part of the pacemaker rpm payload.

rpm -q -f /var/lib/pacemaker is the right query btw.
Comment 34 Fabio Massimo Di Nitto 2013-10-21 13:18:18 EDT
(In reply to Miroslav Grepl from comment #31)
> Who does /var/run/cluster/fence_scsi* create?

fence_scsi does. Same as before.
Comment 35 Miroslav Grepl 2013-10-21 13:27:25 EDT
(In reply to Fabio Massimo Di Nitto from comment #33)
> (In reply to Miroslav Grepl from comment #30)
> > Well I believe pacemaker devs know how this directory is created which we
> > need to know to fix it. Either restorecon will be needed or it should be
> > created in the payload.
> 
> [fabbione@lilith rhel]$ rpm -q -p pacemaker-1.1.10-1.el6_4.4.x86_64.rpm -l
> |grep var/lib
> /var/lib/pacemaker
> /var/lib/pacemaker/blackbox
> /var/lib/pacemaker/cib
> /var/lib/pacemaker/cores
> /var/lib/pacemaker/pengine
> 
> it's part of the pacemaker rpm payload.
> 
> rpm -q -f /var/lib/pacemaker is the right query btw.

I don't think rgmanager works correctly without the latest SELinux changes (easy to find out ... just re-test it with the older z-stream policy) 

cluster_t == rgmanager_t

Ok, if I remove /var/lib/pacemaker and run

# yum reinstall pacemaker
# ls -dZ /var/lib/pacemaker

then I see the correct labeling. So maybe a test issue?
Comment 36 Miroslav Grepl 2013-10-21 13:32:26 EDT
(In reply to Fabio Massimo Di Nitto from comment #34)
> (In reply to Miroslav Grepl from comment #31)
> > Who does /var/run/cluster/fence_scsi* create?
> 
> fence_scsi does. Same as before.

Ok, a new bug here. We need to add labeling for fence_scsi and label it as fenced_exec_t.
Comment 37 Miroslav Grepl 2013-10-21 13:50:06 EDT
Ok and I believe where is the problem with rgmanger+resource scripts. Basically 

generate_name_for_pid_file()

is use. It creates pid files with incorrect labeling. So we need to run restorecon here. The same for pid_dirs() and so on.

So this is a bug in the resource-agents pkg.
Comment 38 Fabio Massimo Di Nitto 2013-10-21 13:54:29 EDT
(In reply to Miroslav Grepl from comment #37)
> Ok and I believe where is the problem with rgmanger+resource scripts.
> Basically 
> 
> generate_name_for_pid_file()
> 
> is use. It creates pid files with incorrect labeling. So we need to run
> restorecon here. The same for pid_dirs() and so on.
> 
> So this is a bug in the resource-agents pkg.

Hardly the case since those scripts have been used by us and customers for 5 point releases of RHEL6.

How is it possible that it come up only now?

So far, what I see, from a user perspective is:

latest 6.4.z works fine, I update selinux-policy and hell breaks loose. Since the resource-agents scripts have not changed in that area, how can I explain that?
Comment 39 Jaroslav Kortus 2013-10-21 14:02:43 EDT
Confirming that the same test (cman+httpd) runs OK on latest 6.4.z:
unconfined_u:system_r:corosync_t:s0 corosync -f
unconfined_u:system_r:fenced_t:s0 fenced
unconfined_u:system_r:dlm_controld_t:s0 dlm_controld
unconfined_u:system_r:gfs_controld_t:s0 gfs_controld
unconfined_u:system_r:cmirrord_t:s0 cmirrord
unconfined_u:system_r:clvmd_t:s0 clvmd -T30
unconfined_u:system_r:rgmanager_t:s0 rgmanager
unconfined_u:system_r:rgmanager_t:s0  \_ rgmanager
unconfined_u:system_r:httpd_t:s0 /usr/sbin/httpd -Dapache -d /etc/httpd -f /etc/cluster/apache/apache:apache/httpd.conf -k start
[root@virt-039 ~]# ausearch -m AVC
<no matches>
[root@virt-039 ~]# rpm -q selinux-policy
selinux-policy-3.7.19-195.el6_4.12.noarch
Comment 41 Miroslav Grepl 2013-10-21 17:02:30 EDT
We have additional fixes in the

selinux-policy-3.7.19-195.el6_4.16

build.

But now we need to run a lot of cluster tests related to cman, heartbeat, corosync to see that we don't have a regression.

Basically resource scripts creates /var/run/cluster/<servicename> dirs. But these pid dirs were created as cluster_var_run_t against var_run_t (as we had it without cluster merge).

So I needed to remove a transition rule which was not a part of rgmanager policy to be sure that all dirs in /var/run/cman are created with var_run_t => we need to be sure all content in /var/run/cluster has a correct label.
Comment 45 Fabio Massimo Di Nitto 2013-10-23 08:58:08 EDT
08:56 < fabbione> mgrepl: i am satisfied with all the tests so far and the latest builds you gave to me..
08:56 < fabbione> no AVC cluster related on both rgmanager and pacemkaer
08:56 < fabbione> both 6.5 and 6.4.z
Comment 46 Jaroslav Kortus 2013-10-23 14:40:15 EDT
no iscsi issues with selinux-policy-3.7.19-195.el6_4.17.noarch
Comment 49 errata-xmlrpc 2013-11-01 09:47:21 EDT
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.

http://rhn.redhat.com/errata/RHBA-2013-1491.html

Note You need to log in before you can comment on or make changes to this bug.