What were you trying to do that didn't work?

A customer is running a NFS server with fapolicyd.
By default, the NFS server cannot serve shared libraries to NFS clients because of rule 8 hitting:

8. deny_audit perm=open all : ftype=application/x-sharedlib

nfsd appears to not be trusted, probably because it's a kernel tasklet.
If it was trusted (which should be the case since it's a standard kernel module), then the dracut exception rule 2 would hit:

2. allow perm=any uid=0 trust=1 : all

But it's not the case.

IMHO we need to add a rule to trust nfsd and let it open all files, e.g.

allow perm=open ppid=2 exe=nfsd : all

Or make nfsd be trusted by default (but how to do that?)

What is the impact of this issue to you?

Doesn't work by default

Please provide the package NVR for which the bug is seen:

fapolicyd-1.3.2-1.el8 and later

How reproducible is this bug?:

Always

Steps to reproduce

1. On the NFS server running fapolicyd, export a share and copy a library into it

   # mkdir -p /var/exports/export1
   # cat /etc/exports
   /var/exports/export1	192.168.122.0/24(rw,sync,no_root_squash,no_subtree_check)
   # cp /lib64/libssl.so.1.1 /var/exports/export1
   

2. On a NFS client, mount the share and try accessing the library

   # mount vm-fapolicyd8:/var/exports/export1 /mnt
   # ldd /mnt/libssl.so.1.1
   

Expected results

ldd returning proper result:

# ldd /mnt/libssl.so.1.1 
	linux-vdso.so.1 (0x00007fff4a3a7000)
	libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f4f266b7000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f4f2649f000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f4f2629b000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4f2607b000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f4f25ca5000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f4f26e37000)

Actual results

# ldd /mnt/libssl.so.1.1
	not a dynamic executable

On NFS server, denial hitting:

rule=8 dec=deny_audit perm=open auid=-1 pid=951 exe=nfsd : path=/var/exports/export1/libssl.so.1.1 ftype=application/x-sharedlib trust=0