Hide Forgot
+++ This bug was initially created as a clone of Bug #1235613 +++ Description of problem: ************************************** CTDB nodes not coming to healthy state after starting ctdb service. SELinux is set to enforcing. type=AVC msg=audit(06/25/2015 02:45:46.844:2625) : avc: denied { write } for pid=22921 comm=net name=ctdbd.socket dev=dm-0 ino=1443389 scontext=unconfined_u:system_r:samba_net_t:s0 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file If we check the context for socket file : srwx------. root root unconfined_u:object_r:var_run_t:s0 /var/run/ctdb/ctdbd.socket after running restorecon -R -v /var/run/ctdb/ctdbd.socket we are again getting the correct context.. After analysis and debugging from development team it looks like the ctdb context has to be set on /usr/sbin/ctdbd_wrapper because this is creating the /var/run/ctdb directory and it will apply the context on the contents of this directory. When we tried to set the context for /usr/sbin/ctdbd_wrapper , remove /var/run/ctdb and then start ctdb service it works fine. so we need same attributes to be set for /usr/sbin/ctdbd_wrapper as it is done for /usr/sbin/ctdbd. Version-Release number of selected component (if applicable): rpm -qa | grep ctdb ctdb2.5-2.5.5-2.el6rhs.x86_64 How reproducible: Always Steps to Reproduce: 1. Install RHEL6.7 , latest gluster rpms, latest samba and ctdb rpms 2. Do ctdb setup 3. Start ctdb service Actual results: CTDB fails to start smb service and remains in UNHEALTHY state. Expected results: CTDB should be able to start smb service and should come to HEALTHY state. Additional info: --- Additional comment from Red Hat Bugzilla Rules Engine on 2015-06-25 06:23:02 EDT --- This bug is automatically being proposed for Red Hat Gluster Storage 3.1.0 by setting the release flag 'rhgs‑3.1.0' to '?'. If this bug should be proposed for a different release, please manually change the proposed release flag. --- Additional comment from surabhi on 2015-06-25 06:45:16 EDT ---
It would be better when the /var/run/ctdb directory was part of ctdb RPM package. The directory would be labeled correctly during the package installation. The ctdbd.socket file in /var/run/ctdb directory would inherit its label from the directory, which is default behavior.
Yes, how Milos wrote above. Is there a chance to add /var/run/ctdb to Gluster RPM? For what is /usr/sbin/ctdbd_wrapper? When is it started? If we add a labeling it could cause additional issue.
(In reply to Miroslav Grepl from comment #2) > Yes, how Milos wrote above. Is there a chance to add /var/run/ctdb to > Gluster RPM? > > For what is /usr/sbin/ctdbd_wrapper? When is it started? If we add a > labeling it could cause additional issue. Setting needinfo on Surabhi for providing the above requested details.
(In reply to Prasanth from comment #3) > (In reply to Miroslav Grepl from comment #2) > > Yes, how Milos wrote above. Is there a chance to add /var/run/ctdb to > > Gluster RPM? /var/run/ctdb belongs to the ctdb RPM, not the gluster RPM. Adding it to gluster would be really strange. > > For what is /usr/sbin/ctdbd_wrapper? When is it started? If we add a > > labeling it could cause additional issue. ctdbd_wrapper is a wrapper around ctdbd which sets a few command line options for ctdbd and also creates /var/run/ctdb if it does not exist. ctdbd_wrapper is the recommended and supported way of starting ctdbd. I personally have no problem with /var/run/ctdb belonging to the ctdb RPM and having the it created by package install - it would be a good idea. Still, if the directory gets removed (by accident or whyever), then ctdbd_wrapper would re-create it. Hence I think we need the setting for ctdbd_wrapper nonetheless.
Sure, it should be a part of ctdbd RPM. Is this a shell script? Could you call restorecon -v /var/run/ctdb after it is created?
(In reply to Miroslav Grepl from comment #5) > Sure, it should be a part of ctdbd RPM. Ok, great. Agreement here. > Is this a shell script? Yes. > Could you call > > restorecon -v /var/run/ctdb > > after it is created? You mean inside the shell script, after running mkdir /var/run/ctdb, run the above restorecon command? In theory that is possible, but this script is part of the upstream tarball. We _could_ patch it for a start. And we would also need start discussing with upstream, whether to include selinux specific calls. It feels slightly out of place in this script, in that it seems at least slightly distribution-specific. What are the dangers or problems associated with giving ctdbd_wrapper the needed state/perms?
Any update?
Ok we just need to test it to see we don't get additional AVCs with chcon -t ctdbd_exec_t /usr/sbin/ctdbd_wrapper The point is it should be really covered by ctdb package. This wrapper is more init script and we should not label init scripts like binaries.
/usr/sbin/ctdbd_wrapper all files system_u:object_r:ctdbd_exec_t:s0 /var/log/core(/.*)? all files system_u:object_r:virt_cache_t:s0 /var/run/ctdb(/.*)? all files system_u:object_r:ctdbd_var_run_t:s0 [root@dhcp159-143 ~]# matchpathcon /usr/sbin/ctdbd_wrapper /usr/sbin/ctdbd_wrapper system_u:object_r:ctdbd_exec_t:s0 [root@dhcp159-143 ~]# ls -Z /usr/sbin/ctdbd_wrapper -rwxr-xr-x. root root system_u:object_r:ctdbd_exec_t:s0 /usr/sbin/ctdbd_wrapper It looks correct to me. Basically we don't care about unconfined_u. It means a label has been changed by a user. The problem is we see unconfined_t instead of ctdbd_t for ctdbd process.
Also I see #service ctdb start #ps -eZ|grep ctdb unconfined_u:system_r:ctdbd_t:s0 20047 ? 00:00:00 ctdbd unconfined_u:system_r:ctdbd_t:s0 20200 ? 00:00:00 ctdb_recovered So it looks correct. It means you need to start it without init script.
(In reply to Miroslav Grepl from comment #9) > /usr/sbin/ctdbd_wrapper all files > system_u:object_r:ctdbd_exec_t:s0 > /var/log/core(/.*)? all files > system_u:object_r:virt_cache_t:s0 > /var/run/ctdb(/.*)? all files > system_u:object_r:ctdbd_var_run_t:s0 > [root@dhcp159-143 ~]# matchpathcon /usr/sbin/ctdbd_wrapper > /usr/sbin/ctdbd_wrapper system_u:object_r:ctdbd_exec_t:s0 > [root@dhcp159-143 ~]# ls -Z /usr/sbin/ctdbd_wrapper > -rwxr-xr-x. root root system_u:object_r:ctdbd_exec_t:s0 > /usr/sbin/ctdbd_wrapper > > It looks correct to me. > > Basically we don't care about unconfined_u. It means a label has been > changed by a user. > > The problem is we see unconfined_t instead of ctdbd_t for ctdbd process. Wait! We have set all the system_u flags manually with chcon. They all were at unconfined_u. Also, should this comment have gone into BZ #1235613 ?
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-2016-0763.html