*** Bug 1961311 has been marked as a duplicate of this bug. ***

(In reply to Renaud Métrich from comment #0)
> Description of problem:
> 
> Starting fapolicyd on a system shows the following AVC:
> -------- 8< ---------------- 8< ---------------- 8< ---------------- 8<
> --------
> time->Tue Mar 30 13:50:08 2021
> type=PROCTITLE msg=audit(1617105008.790:241):
> proctitle=2F7573722F7362696E2F6661706F6C69637964002D2D7065726D697373697665002
> D2D64656275672D64656E79
> type=SYSCALL msg=audit(1617105008.790:241): arch=c000003e syscall=257
> success=no exit=-13 a0=ffffff9c a1=55830f6c8980 a2=42 a3=1a4 items=0 ppid=1
> pid=2209 auid=4294967295 uid=994 gid=991 euid=994 suid=994 fsuid=994
> egid=991 sgid=991 fsgid=991 tty=(none) ses=4294967295 comm="fapolicyd"
> exe="/usr/sbin/fapolicyd" subj=system_u:system_r:fapolicyd_t:s0 key=(null)
> type=AVC msg=audit(1617105008.790:241): avc:  denied  { write } for 
> pid=2209 comm="fapolicyd" name="rpm" dev="dm-0" ino=134
> scontext=system_u:system_r:fapolicyd_t:s0
> tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=dir permissive=0
> -------- 8< ---------------- 8< ---------------- 8< ---------------- 8<
> --------
> 
> This happens because fapolicyd tries to open the RPM database, causing the
> lock file to be created (if it doesn't exist).
> 
> 
> Version-Release number of selected component (if applicable):
> 
> fapolicyd-1.0-3.el8_3.4.x86_64
> 
> 
> How reproducible:
> 
> Always
> 
> Steps to Reproduce:
> 1. Start fapolicyd as a service
> 
> Actual results:
> 
> AVC
> 
> Expected results:
> 
> No AVC or AVC hidden
> 
> Additional info:
> 
> Since fapolicyd is just reading the database, I think we can add a dontaudit
> rule:
> 
> # echo '(dontaudit fapolicyd_t rpm_var_lib_t (dir (write)))' >
> dontaudit-fapolicyd-rpmlock.cil
> # semodule -i dontaudit-fapolicyd-rpmlock.cil

I am trying to replicate this issue but I am not getting any avc. I tried this on a fresh rhel-8.6 and rhel-8.3 instance.
On rhel-8.3 I even have the same version of fapolicyd (fapolicyd-1.0-3.el8_3.4.x86_64), but no avc.

Do I understand correctly that this should trigger the avc?

# systemctl start fapolicyd
# ausearch -m avc -ts recent
<no matches>

This seems to be fixed with 8.4 (commit 8f1a028cebf6cdcea4e57acf26f77c438b9d4982, 1.0.2-2):

diff --git a/selinux.patch b/selinux.patch
[...]
+ optional_policy(`
+-        rpm_read_db(fapolicyd_t)        
++        rpm_read_db(fapolicyd_t)
++        allow fapolicyd_t rpm_var_lib_t:file { create };
++        allow fapolicyd_t rpm_var_lib_t:dir { add_name write };
+ ')


On 8.3 (fapolicyd-1.0-3.el8_3.4.x86_64), I can reproduce by starting the service after making sure no lock file is present in /var/lib/rpm:

# systemctl enable fapolicyd
# rm /var/lib/rpm/*.lock
# reboot

...

# ausearch -m avc,user_avc -ts boot -i
----
type=AVC msg=audit(11/08/2021 08:10:27.145:5) : avc:  denied  { write } for  pid=1067 comm=fapolicyd name=rpm dev="dm-0" ino=134 scontext=system_u:system_r:fapolicyd_t:s0 tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=dir permissive=0 

Not sure we need a fix on 8.3 since 8.3 has no EUS.

As the necessary selinux rules are present and this is not an issue on rhel-8.6, I will close this bz as "NOTABUG".
So far there is no plan to fix this on rhel-8.3.