Hi Kaleb,

I have opened https://github.com/gluster/glusterfs/issues/1830%C2%A0.

I was not sure where to open it ,as I saw that 'nfs-ganesha-selinux-3.3-2.el8.noarch' rpm provided by the storage SIG repo  'centos-nfs-ganesha3'.

I'm adding the Gluster devel here,as the current version of NFS Ganesha will not be usable without proper workaround in the SELINUX policy.

Best Regards, Strahil Nikolov

В неделя, 22 ноември 2020 г., 22:47:42 Гринуич+2, Kaleb Keithley kkeithle@redhat.com написа:

On Sat, Nov 21, 2020 at 4:48 PM Strahil Nikolov hunter86_bg@yahoo.com wrote:

Hi All,

The reason seems to be the link "/var/lib/nfs" pointing to the shared storage.When the cluster software is stopped gracefully, no issues are observed,as the nfs_setup resource restores /var/lib/nfs .

Should I open a bug to bugzilla.redhat.com or it's specific to CentOS only ?

Not sure what you'd file it under.

I'd suggest opening an issue in github at https://github.com/gluster/glusterfs/issues

--

Kaleb

Can you collect any AVC messages from /var/log/audit/audit.log or /var/log/messsages, or dmesg on the host that would only boot after setting enforcing=0?

Thanks

On Mon, Nov 23, 2020 at 7:55 AM Kaleb Keithley kkeithle@redhat.com wrote:

On Sat, Nov 21, 2020 at 4:48 PM Strahil Nikolov hunter86_bg@yahoo.com wrote:

...

Hi All,

I have been testing EL8 + NFS Ganesha 3 (from CentOS Storage SIG) and Gluster v8 (tested both Storage SIG rpms and built from source ) and I have noticed a bug in the SELINUX policy causing the system to fail to boot after the node is fenced until a kernel parameter 'enforcing=0' is passed.

The reason seems to be the link "/var/lib/nfs" pointing to the shared storage.When the cluster software is stopped gracefully, no issues are observed,as the nfs_setup resource restores /var/lib/nfs .

Should I open a bug to bugzilla.redhat.com or it's specific to CentOS only ?

Off hand I don't think that's a bug in the nfs-ganesha-selinux package. I've asked the cluster (pacemaker, etc.) devs and the selinux devs what they think. You asked about opening a BZ in bugzilla.redhat.com; but https://github.com/gluster/glusterfs/issues is the correct place to report gluster issues.

For this though I suggest opening an issue in https://github.com/ClusterLabs/ somewhere, maybe https://github.com/ClusterLabs/fence-agents/issues? So it doesn't get lost.

...

More details: [root@glustere ~]# rpm -qa | grep ganesha | sort centos-release-nfs-ganesha30-1.0-2.el8.noarch glusterfs-ganesha-8.2-0.5.git77eb5e838.el8.x86_64 nfs-ganesha-3.3-2.el8.x86_64 nfs-ganesha-gluster-3.3-2.el8.x86_64 nfs-ganesha-selinux-3.3-2.el8.noarch

[root@glustere ~]# dmesg | grep -e type=1300 -e type=1400 [ 14.414782] audit: type=1400 audit(1605994499.985:3): avc: denied { getattr } for pid=1 comm="systemd" path="/var/lib/nfs" dev="dm-0" ino=33596932 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:var_lib_nfs_t:s0 tclass=lnk_file permissive=1

[root@glustere ~]# dmesg | grep -e type=1300 -e type=1400 | audit2allow -M my-systemd ******************** IMPORTANT *********************** To make this policy package active, execute:

semodule -i my-systemd.pp

[root@glustere ~]# cat my-systemd.te

module my-systemd 1.0;

require { type var_lib_nfs_t; type init_t; class lnk_file getattr; }

#============= init_t ============== allow init_t var_lib_nfs_t:lnk_file getattr;

Best Regards, Strahil Nikolov