Red Hat Bugzilla – Bug 1508360
selinux inhibits pacemaker's logging policy
Last modified: 2018-04-10 08:46:56 EDT
Description of problem: By default, pacemaker maps /var/log/pacemaker/bundles/{container_name} on the host to /var/log in the container, however selinux blocks all access such that even 'ls -al /var/log' from within the container fails (regardless of the permissions on /var/log/pacemaker/bundles/* This essentially sends all logging inside the container to /dev/null and makes debugging near impossible. Disabling selinux allows logs to be created, so presumably there is some policy change that will allow this to function. Version-Release number of selected component (if applicable): selinux-policy-3.13.1-166.el7.noarch libselinux-2.5-11.el7.i686 container-selinux-2.21-2.gitba103ac.el7.noarch How reproducible: 100% Steps to Reproduce: 1. mkdir -p /var/log/pacemaker/bundles/somename 2. Spawn a foreground container with -v /var/log/pacemaker/bundles/somename:/var/log and /bin/bash as the run command. 3. ls -al /var/log && echo success >> /var/log/somefile Actual results: /var/log/pacemaker/bundles/somename is empty Expected results: /var/log/pacemaker/bundles/somename/somefile contains 'success'
I can't reproduce this. I can start a pacemaker bundle, and it is able to write to /var/log/pacemaker/bundles/httpd-bundle-0/pacemaker.log without any SELinux denials. I can also run docker exec httpd-bundle-docker-0 /bin/sh -c 'echo hello > /var/log/hello' and the file is created without any SELinux denials. It's possible your /var/log doesn't have its default context. Try: restorecon -R -v /var/log/pacemaker/bundles and see if it works after that.
You may also need to do this to make it take effect immediately: chcon -R -t var_log_t /var/log/pacemaker/bundles You can confirm by checking for var_log_t in: ls -aZ /var/log/pacemaker/bundles
Doesn't look like thats something that's present by default. Admin shouldn't have to run this by hand on every newly deployed machine [root@c09-h05-r630 ~]# ls -aZ /var/log/pacemaker/bundles | head -n 5 drwxr-x--x. root root system_u:object_r:cluster_var_log_t:s0 . drwxr-x--x. root root system_u:object_r:cluster_var_log_t:s0 .. drwxr-x--x. root root system_u:object_r:cluster_var_log_t:s0 scale10-bundle-1 drwxr-x--x. root root system_u:object_r:cluster_var_log_t:s0 scale10-bundle-11 drwxr-x--x. root root system_u:object_r:cluster_var_log_t:s0 scale10-bundle-2 [root@c09-h05-r630 ~]# chcon -R -t var_log_t /var/log/pacemaker/bundles [root@c09-h05-r630 ~]# ls -aZ /var/log/pacemaker/bundles | head -n 5 drwxr-x--x. root root system_u:object_r:var_log_t:s0 . drwxr-x--x. root root system_u:object_r:cluster_var_log_t:s0 .. drwxr-x--x. root root system_u:object_r:var_log_t:s0 scale10-bundle-1 drwxr-x--x. root root system_u:object_r:var_log_t:s0 scale10-bundle-11 drwxr-x--x. root root system_u:object_r:var_log_t:s0 scale10-bundle-2
Interesting, /var/log/pacemaker defaulted to var_log_t on my test cluster, not cluster_var_log_t. That may have changed since I created it.
Re-assigning to the selinux-policy component. The issue appears to be that /var/log/pacemaker/bundles defaults to cluster_var_log_t under some policy, and cluster_var_log_t does not allow writes by isolated environments (the way svirt_sandbox_file_t and apparently var_log_t do). On my updated 7.4 machine with selinux-policy-targeted, /etc/selinux/targeted/contexts/files/file_contexts doesn't apply cluster_var_log_t to /var/log/pacemaker/bundles, so I'm not sure where that's coming from. The reporter no longer has the test machines that originally exhibited the issue, but they were likely generic 7.4 installs. The Pacemaker upstream plans to switch the default location for these to /var/log/cluster/bundles soon, so it would be a good idea to treat both /var/log/pacemaker/bundles and /var/log/cluster/bundles identically. I think var_log_t makes more sense than cluster_var_log_t for these, since they are what it is exported as /var/log to Docker containers managed by Pacemaker. They would be expected to contain logs generated by the cluster software, but likely also other logs generated by software inside the container. In any case, the default SELinux policy should allow Docker containers to write to subdirectories of these two directories.
SELinux policy does not define more specific label for /var/log/pacemaker or /var/log/cluster directory in comparison with /var/log directory: # matchpathcon /var/log/ /var/log system_u:object_r:var_log_t:s0 # matchpathcon /var/log/pacemaker /var/log/pacemaker system_u:object_r:var_log_t:s0 # matchpathcon /var/log/cluster /var/log/cluster system_u:object_r:var_log_t:s0 # but comment#4 describes a situation where files and directories are labeled cluster_var_log_t. It seems that /var/log/pacemaker directory and its subdirectories are created by a process running under cluster_t, because that is the only SELinux domain which does that by default: # sesearch -T -t var_log_t -c dir | grep ' cluster_var_log_t' type_transition cluster_t var_log_t : dir cluster_var_log_t; # I have to point out that if you run "restorecon -Rv /var/log" on the host, the cluster_var_log_t labels will be gone, because SELinux policy considers cluster_var_log_t label as correct for following paths only: # semanage fcontext -l | grep cluster_var_log_t /var/log/pcsd(/.*)? all files system_u:object_r:cluster_var_log_t:s0 /var/log/clumond\.log.* regular file system_u:object_r:ricci_modcluster_var_log_t:s0 /var/log/pacemaker\.log.* regular file system_u:object_r:cluster_var_log_t:s0 /var/log/cluster/aisexec\.log.* regular file system_u:object_r:cluster_var_log_t:s0 /var/log/cluster/cpglockd\.log.* regular file system_u:object_r:cluster_var_log_t:s0 /var/log/cluster/corosync\.log.* regular file system_u:object_r:cluster_var_log_t:s0 /var/log/cluster/rgmanager\.log.* regular file system_u:object_r:cluster_var_log_t:s0 #
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://access.redhat.com/errata/RHBA-2018:0763