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