Description of problem: I see multiple of these denials on boot of a current F34 system (with all updates from updates-testing). `/etc/NetworkManager/VPN/` directory is empty and claimed not owned by any package, I'm not sure how it comes to exist. SELinux is preventing gmain from 'watch' accesses on the directory /etc/NetworkManager/VPN. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that gmain should be allowed watch access on the VPN directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'gmain' --raw | audit2allow -M my-gmain # semodule -X 300 -i my-gmain.pp Additional Information: Source Context system_u:system_r:NetworkManager_t:s0 Target Context system_u:object_r:NetworkManager_etc_t:s0 Target Objects /etc/NetworkManager/VPN [ dir ] Source gmain Source Path gmain Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-3.14.7-25.fc34.noarch Local Policy RPM selinux-policy-targeted-3.14.7-25.fc34.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 5.11.6-300.fc34.x86_64 #1 SMP Thu Mar 11 17:58:00 UTC 2021 x86_64 x86_64 Alert Count 7 First Seen 2021-03-15 12:17:36 PDT Last Seen 2021-03-15 12:18:00 PDT Local ID c78c76bd-140a-4165-8e71-cd7dc5f73451 Raw Audit Messages type=AVC msg=audit(1615835880.308:1034): avc: denied { watch } for pid=1134 comm="gmain" path="/etc/NetworkManager/VPN" dev="dm-1" ino=2621585 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:NetworkManager_etc_t:s0 tclass=dir permissive=0 Hash: gmain,NetworkManager_t,NetworkManager_etc_t,dir,watch Version-Release number of selected component: selinux-policy-targeted-3.14.7-25.fc34.noarch Additional info: component: selinux-policy reporter: libreport-2.14.0 hashmarkername: setroubleshoot kernel: 5.11.6-300.fc34.x86_64 type: libreport
*** This bug has been marked as a duplicate of bug 1934725 ***