[CentOS-devel] NFS Ganesha (Storage SIG) node fails to boot after fencing

Hi Vit,


the generated policy fixes the issue. I've opened an issue at https://github.com/ClusterLabs/fence-agents/issues/368

@Kaleb Keithley ,
It's already in the previous e-mail and in the issue I just created.

Best Regards,
Strahil Nikolov






В понеделник, 23 ноември 2020 г., 16:28:01 Гринуич+2, Vit Mojzis <vmojzis at redhat.com> написа: 






Hi,

based on the policy module generated by audit2allow it seems that this is an issue in the base policy (selinux-policy package).
Init_t is only allowed to access files and directories labeled var_lib_nfs_t (and not link_files). But I believe "getattr" permission was added in rhel-8.3.

Does the generated policy module (my-systemd) resolve the issue?

Vit





On 11/23/20 2:54 PM, Kaleb Keithley wrote:


>  


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 at redhat.com> wrote:


>  
>  
> 
> 
> 
> 
>  
> On Sat, Nov 21, 2020 at 4:48 PM Strahil Nikolov <hunter86_bg at 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 at 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 at 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 at 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 at 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
>> 
>> 
> 
> 
>