Bug 1235636

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