Description of problem: refresh-config fails with denial AVC related to /usr/bin/dbus-daemon Version-Release number of selected component (if applicable): glusterfs-3.7.9-5 nfs-ganesha-2.3.1-7 selinux-policy-3.13.1-60.el7_2.5.noarch How reproducible: Always Steps to Reproduce: 1.Create a 4 node ganesha cluster. 2.Create a volume and enable ganesha on it 3.Change some parameter in volume export file and perform a refresh config on the volume. Observe that it fails and below USER_AVC is seen in audit.log [root@dhcp37-44 exports]# /usr/libexec/ganesha/ganesha-ha.sh --refresh-config /etc/ganesha/ testvolume Error: refresh-config failed on dhcp37-111 following AVC is seen in audit.log type=USER_AVC msg=audit(1463444111.125:18338): pid=652 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_return dest=:1.3942 spid=31935 tpid=32163 scontext=system_u:system_r:glusterd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=dbus exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' Actual results: There should not be any denial AVC's Expected results: refresh config should work as expected Additional info: performed the same test on previous builds and it works fine: glusterfs-3.7.9-3.el7rhgs.x86_64 nfs-ganesha-2.3.1-4.el7rhgs.x86_64 selinux-policy-3.13.1-60.el7_2.3.noarch [root@dhcp46-247 exports]# /usr/libexec/ganesha/ganesha-ha.sh --refresh-config /etc/ganesha/ testvolume Refresh-config completed on dhcp46-202. Refresh-config completed on dhcp46-26. Refresh-config completed on dhcp47-139. Success: refresh-config completed.
workaround: use selinux-policy-3.13.1-60.el7_2.4.noarch
kaleb, Verified with selinux-policy-3.13.1-60.el7_2.4.noarch too and the issue is reproducible even with that. We did not find this issue before because of the bug (https://bugzilla.redhat.com/show_bug.cgi?id=1335114), which anyways was failing the refresh config scenario. So comment 3 does not stands true.
Could you run following command on the machine where the SELinux denial appared? # ps -efZ | grep -e dbus -e glusterd_t -e unconfined_t
[root@dhcp37-111 exports]# ps -efZ | grep -e dbus -e glusterd_t -e unconfined_t system_u:system_r:glusterd_t:s0 root 455 1 0 04:32 ? 00:00:02 /usr/sbin/glusterfsd -s dhcp37-111.lab.eng.blr.redhat.com --volfile-id gluster_shared_storage.dhcp37-111.lab.eng.blr.redhat.com.var-lib-glusterd-ss_brick -p /var/lib/glusterd/vols/gluster_shared_storage/run/dhcp37-111.lab.eng.blr.redhat.com-var-lib-glusterd-ss_brick.pid -S /var/run/gluster/0c6fa384ea02f468bee22980c5b7a3de.socket --brick-name /var/lib/glusterd/ss_brick -l /var/log/glusterfs/bricks/var-lib-glusterd-ss_brick.log --xlator-option *-posix.glusterd-uuid=8df6b00a-e1fb-4139-a454-5042dd16f800 --brick-port 49152 --xlator-option gluster_shared_storage-server.listen-port=49152 system_u:system_r:glusterd_t:s0 root 608 1 0 07:09 ? 00:00:00 /usr/bin/ganesha.nfsd -L /var/log/ganesha.log -f /etc/ganesha/ganesha.conf -N NIV_EVENT -E 6285466248312979456 system_u:system_r:glusterd_t:s0 root 617 1 0 04:33 ? 00:00:00 /usr/sbin/glusterfs --volfile-server=dhcp37-111.lab.eng.blr.redhat.com --volfile-id=/gluster_shared_storage /run/gluster/shared_storage system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 dbus 652 1 0 May16 ? 00:00:27 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation system_u:system_r:glusterd_t:s0 root 1874 1 0 07:11 ? 00:00:00 /usr/sbin/glusterfsd -s 10.70.37.111 --volfile-id testvolume.10.70.37.111.bricks-brick0-b0 -p /var/lib/glusterd/vols/testvolume/run/10.70.37.111-bricks-brick0-b0.pid -S /var/run/gluster/277f694509a8f729fef832deaec9d4f4.socket --brick-name /bricks/brick0/b0 -l /var/log/glusterfs/bricks/bricks-brick0-b0.log --xlator-option *-posix.glusterd-uuid=8df6b00a-e1fb-4139-a454-5042dd16f800 --brick-port 49155 --xlator-option testvolume-server.listen-port=49155 system_u:system_r:glusterd_t:s0 root 1893 1 0 07:11 ? 00:00:00 /usr/sbin/glusterfsd -s 10.70.37.111 --volfile-id testvolume.10.70.37.111.bricks-brick1-b1 -p /var/lib/glusterd/vols/testvolume/run/10.70.37.111-bricks-brick1-b1.pid -S /var/run/gluster/ff162f438a39d11cb362ab4b58bebead.socket --brick-name /bricks/brick1/b1 -l /var/log/glusterfs/bricks/bricks-brick1-b1.log --xlator-option *-posix.glusterd-uuid=8df6b00a-e1fb-4139-a454-5042dd16f800 --brick-port 49156 --xlator-option testvolume-server.listen-port=49156 system_u:system_r:glusterd_t:s0 root 1912 1 0 07:11 ? 00:00:00 /usr/sbin/glusterfsd -s 10.70.37.111 --volfile-id testvolume.10.70.37.111.bricks-brick2-b2 -p /var/lib/glusterd/vols/testvolume/run/10.70.37.111-bricks-brick2-b2.pid -S /var/run/gluster/a5e973fce4e4fe26d5f9c2e5423aa0f1.socket --brick-name /bricks/brick2/b2 -l /var/log/glusterfs/bricks/bricks-brick2-b2.log --xlator-option *-posix.glusterd-uuid=8df6b00a-e1fb-4139-a454-5042dd16f800 --brick-port 49157 --xlator-option testvolume-server.listen-port=49157 system_u:system_r:glusterd_t:s0 root 1932 1 0 07:11 ? 00:00:00 /usr/sbin/glusterfs -s localhost --volfile-id gluster/glustershd -p /var/lib/glusterd/glustershd/run/glustershd.pid -l /var/log/glusterfs/glustershd.log -S /var/run/gluster/cc05dec3b7775280378419526ab79218.socket --xlator-option *replicate*.node-uuid=8df6b00a-e1fb-4139-a454-5042dd16f800 unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 3618 30089 0 07:15 pts/0 00:00:00 ps -efZ unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 3619 30089 0 07:15 pts/0 00:00:00 grep --color=auto -e dbus -e glusterd_t -e unconfined_t unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 7645 1273 0 04:46 ? 00:00:00 sshd: root@pts/1 unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 7656 7645 0 04:46 pts/1 00:00:00 -bash unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 30054 1273 0 04:16 ? 00:00:00 sshd: root@pts/0 unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 30089 30054 0 04:17 pts/0 00:00:00 -bash system_u:system_r:glusterd_t:s0 root 31540 1 0 04:29 ? 00:00:02 /usr/sbin/glusterd -p /var/run/glusterd.pid --log-level INFO
Before the workaround: [root@dhcp42-20 ~]# getenforce Enforcing [root@dhcp42-20 ~]# /usr/libexec/ganesha/ganesha-ha.sh --refresh-config /etc/ganesha/ newvolume Error: refresh-config failed on dhcp42-196. following AVC is seen: type=USER_AVC msg=audit(1463759842.739:27057): pid=1248 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_return dest=:1.7081 spid=13623 tpid=19605 scontext=system_u:system_r:glusterd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=dbus exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' After the workaround: [root@dhcp42-20 ~]# /usr/libexec/ganesha/ganesha-ha.sh --refresh-config /etc/ganesha/ newvolume Refresh-config completed on dhcp42-196. Warning: Permanently added 'dhcp42-239' (ECDSA) to the list of known hosts. Refresh-config completed on dhcp42-239. Warning: Permanently added 'dhcp43-175' (ECDSA) to the list of known hosts. Refresh-config completed on dhcp43-175. Success: refresh-config completed. No AVC seen in audit.log So the given local policy works fine and the earlier reported issue is not seen.
Verified this bug with 7.3 related selinux policy: [root@dhcp42-22 exports]# rpm -qa|grep selinux selinux-policy-3.13.1-74.el7.noarch selinux-policy-targeted-3.13.1-74.el7.noarch and no issues are seen during refresh config: [root@dhcp42-156 exports]# /usr/libexec/ganesha/ganesha-ha.sh --refresh-config /etc/ganesha/ testvolume Warning: Permanently added 'dhcp42-22,10.70.42.22' (ECDSA) to the list of known hosts. Refresh-config completed on dhcp42-22. Success: refresh-config completed.
Verified this bug with latest selinux-policy for RHEL 7.2 and it works as expected: [root@dhcp46-247 exports]# rpm -qa|grep selinux selinux-policy-targeted-3.13.1-60.el7_2.6.noarch selinux-policy-devel-3.13.1-60.el7_2.6.noarch selinux-policy-3.13.1-60.el7_2.6.noarch Refresh config on volume works fine and no denial AVC's are seen in audit.log [root@dhcp46-247 exports]# /usr/libexec/ganesha/ganesha-ha.sh --refresh-config /etc/ganesha/ testvolume Refresh-config completed on dhcp46-202. Refresh-config completed on dhcp46-26. Refresh-config completed on dhcp47-139. Success: refresh-config completed. Based on above observation, marking this bug as Verified.
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/RHEA-2016:1247