Description of problem: SELinux is preventing abrt-action-sav from write access on the file /var/lib/rpm/rpmdb.sqlite-wal. ***** Plugin catchall_labels (83.8 confidence) suggests ******************* If you want to allow abrt-action-sav to have write access on the rpmdb.sqlite-wal file Then you need to change the label on /var/lib/rpm/rpmdb.sqlite-wal Do # semanage fcontext -a -t FILE_TYPE '/var/lib/rpm/rpmdb.sqlite-wal' where FILE_TYPE is one of the following: abrt_etc_t, abrt_tmp_t, abrt_upload_watch_tmp_t, abrt_var_cache_t, abrt_var_log_t, abrt_var_run_t, afs_cache_t, initrc_tmp_t, kdump_crash_t, mail_home_rw_t, mock_var_lib_t, postfix_postdrop_t, puppet_tmp_t, rhsmcertd_var_run_t, rpm_log_t, rpm_var_cache_t, rpm_var_run_t, sysfs_t, user_cron_spool_t, user_tmp_t, usr_t. Then execute: restorecon -v '/var/lib/rpm/rpmdb.sqlite-wal' ***** Plugin catchall (17.1 confidence) suggests ************************** If you believe that abrt-action-sav should be allowed write access on the rpmdb.sqlite-wal file 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 'abrt-action-sav' --raw | audit2allow -M my-abrtactionsav # semodule -X 300 -i my-abrtactionsav.pp Additional Information: Source Context system_u:system_r:abrt_t:s0-s0:c0.c1023 Target Context system_u:object_r:var_lib_t:s0 Target Objects /var/lib/rpm/rpmdb.sqlite-wal [ file ] Source abrt-action-sav Source Path abrt-action-sav Port <Unknown> Host hal9000 Source RPM Packages Target RPM Packages SELinux Policy RPM <Unknown> Local Policy RPM selinux-policy-targeted-3.14.6-29.fc33.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name hal9000 Platform Linux hal9000 5.8.17-300.fc33.x86_64 #1 SMP Thu Oct 29 15:55:40 UTC 2020 x86_64 x86_64 Alert Count 585 First Seen 2020-11-03 00:46:06 CST Last Seen 2020-11-04 16:22:37 CST Local ID 75106fca-ff74-417c-97be-6e1161aa5010 Raw Audit Messages type=AVC msg=audit(1604528557.413:498): avc: denied { write } for pid=3321 comm="abrt-action-lis" name="rpmdb.sqlite-wal" dev="zfs" ino=32898 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0 Hash: abrt-action-sav,abrt_t,var_lib_t,file,write Version-Release number of selected component (if applicable): abrt-2.14.4-7.fc33.x86_64 How reproducible: I've see two of these so far. I upgraded to Fedora 33 about 2 days ago. Steps to Reproduce: Not sure. It might be happening on reboots. Actual results: Expected results: Additional info: I don't see any obvious problems, but I don't know exactly what it is that is being blocked. This report is more of an FYI at the moment.
same for me, Fedora 33, just updates some days ago. SELinux log is flooding with errors like: time->Thu Nov 5 18:21:12 2020 type=AVC msg=audit(1604596872.429:34006): avc: denied { read } for pid=4421 comm="rpm" name="rpmdb.sqlite" dev="dm-6" ino=155 scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0 ---- time->Thu Nov 5 18:21:12 2020 type=AVC msg=audit(1604596872.429:34007): avc: denied { read } for pid=4421 comm="rpm" name="rpmdb.sqlite" dev="dm-6" ino=155 scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0 ---- and causing high cpu usage for setroubleshootd. Downgrading to selinux-policiy-target 3.14.6-28.fc33 seems to solve it.
I'm getting a similar error that I assume is related with "setattr": SELinux is preventing abrt-action-sav from setattr access on the file rpmdb.sqlite-wal. ***** Plugin catchall_labels (83.8 confidence) suggests ******************* If you want to allow abrt-action-sav to have setattr access on the rpmdb.sqlite-wal file Then you need to change the label on rpmdb.sqlite-wal Do # semanage fcontext -a -t FILE_TYPE 'rpmdb.sqlite-wal' where FILE_TYPE is one of the following: abrt_tmp_t, abrt_upload_watch_tmp_t, abrt_var_cache_t, abrt_var_log_t, abrt_var_run_t, kdump_crash_t, mail_home_rw_t, mock_var_lib_t, rhsmcertd_var_run_t, rpm_log_t, rpm_var_cache_t, rpm_var_run_t, usr_t. Then execute: restorecon -v 'rpmdb.sqlite-wal' ***** Plugin catchall (17.1 confidence) suggests ************************** If you believe that abrt-action-sav should be allowed setattr access on the rpmdb.sqlite-wal file 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 'abrt-action-sav' --raw | audit2allow -M my-abrtactionsav # semodule -X 300 -i my-abrtactionsav.pp Additional Information: Source Context system_u:system_r:abrt_t:s0-s0:c0.c1023 Target Context system_u:object_r:var_lib_t:s0 Target Objects rpmdb.sqlite-wal [ file ] Source abrt-action-sav Source Path abrt-action-sav Port <Unknown> Host hp Source RPM Packages Target RPM Packages SELinux Policy RPM <Unknown> Local Policy RPM selinux-policy-targeted-3.14.6-29.fc33.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name hp Platform Linux hp 5.8.17-300.fc33.x86_64 #1 SMP Thu Oct 29 15:55:40 UTC 2020 x86_64 x86_64 Alert Count 91 First Seen 2020-11-05 11:54:51 MST Last Seen 2020-11-05 11:54:52 MST Local ID 2df1b1b4-9611-47a9-8f55-06f12e937ce5 Raw Audit Messages type=AVC msg=audit(1604602492.403:691): avc: denied { setattr } for pid=119078 comm="abrt-action-lis" name="rpmdb.sqlite-wal" dev="dm-0" ino=918541 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0 Hash: abrt-action-sav,abrt_t,var_lib_t,file,setattr
Hello, I also have a similar issue after upgrading from F32 to F33 but for "abrt-action-lis". It happens everyday, probably after booting up. Below is an excerpt: type=AVC msg=audit(1604591214.135:316): avc: denied { write } for pid=2657 comm="abrt-action-lis" name="rpmdb.sqlite-wal" dev="sda3" ino=270154249 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0 type=AVC msg=audit(1604591214.135:317): avc: denied { setattr } for pid=2657 comm="abrt-action-lis" name="rpmdb.sqlite-wal" dev="sda3" ino=270154249 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0 type=AVC msg=audit(1604591214.136:318): avc: denied { write } for pid=2657 comm="abrt-action-lis" name="rpmdb.sqlite-wal" dev="sda3" ino=270154249 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0 type=AVC msg=audit(1604591214.136:319): avc: denied { setattr } for pid=2657 comm="abrt-action-lis" name="rpmdb.sqlite-wal" dev="sda3" ino=270154249 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0 type=AVC msg=audit(1604591214.137:320): avc: denied { write } for pid=2657 comm="abrt-action-lis" name="rpmdb.sqlite-wal" dev="sda3" ino=270154249 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0 type=AVC msg=audit(1604591214.137:321): avc: denied { setattr } for pid=2657 comm="abrt-action-lis" name="rpmdb.sqlite-wal" dev="sda3" ino=270154249 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0 type=AVC msg=audit(1604591214.138:322): avc: denied { write } for pid=2657 comm="abrt-action-lis" name="rpmdb.sqlite-wal" dev="sda3" ino=270154249 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0 type=AVC msg=audit(1604591214.138:323): avc: denied { setattr } for pid=2657 comm="abrt-action-lis" name="rpmdb.sqlite-wal" dev="sda3" ino=270154249 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0
I also have the setattr and the write issue each second roughly. I tried to fix the context: ``` $ ll -Z /var/lib/rpm/rpmdb.sqlite-wal -rw-r--r--. 1 root root system_u:object_r:var_lib_t:s0 0 Nov 7 08:56 /var/lib/rpm/rpmdb.sqlite-wal $ sudo /sbin/restorecon -v /var/lib/rpm/rpmdb.sqlite-wal Relabeled /var/lib/rpm/rpmdb.sqlite-wal from system_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 $ ll -Z /var/lib/rpm/rpmdb.sqlite-wal -rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0 0 Nov 7 08:56 /var/lib/rpm/rpmdb.sqlite-wal ``` And the issue stopped to appear after a few seconds. No clue where the issue came from initially.
I got two more notifications (at least not a series), but this time for `/var/lib/rpm/rpmdb.sqlite-shm`, once because of setattr, once because of write. ``` $ ll -aZ /var/lib/rpm/ total 209504 drwxr-xr-x. 2 root root system_u:object_r:var_lib_t:s0 4096 Oct 31 10:14 . drwxr-xr-x. 76 root root system_u:object_r:var_lib_t:s0 4096 Nov 7 08:54 .. -rw-r--r--. 1 root root system_u:object_r:var_lib_t:s0 214487040 Nov 8 10:07 rpmdb.sqlite -rw-r--r--. 1 root root system_u:object_r:var_lib_t:s0 32768 Nov 8 10:11 rpmdb.sqlite-shm -rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0 0 Nov 8 10:07 rpmdb.sqlite-wal -rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0 0 Oct 31 10:14 .rpm.lock $ sudo restorecon -Rv /var/lib/rpm/ Relabeled /var/lib/rpm from system_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/.rpm.lock from unconfined_u:object_r:var_lib_t:s0 to unconfined_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/rpmdb.sqlite from system_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/rpmdb.sqlite-shm from system_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 $ ll -aZ /var/lib/rpm/ total 209504 drwxr-xr-x. 2 root root system_u:object_r:rpm_var_lib_t:s0 4096 Oct 31 10:14 . drwxr-xr-x. 76 root root system_u:object_r:var_lib_t:s0 4096 Nov 7 08:54 .. -rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0 214487040 Nov 8 10:07 rpmdb.sqlite -rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0 32768 Nov 8 10:11 rpmdb.sqlite-shm -rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0 0 Nov 8 10:07 rpmdb.sqlite-wal -rw-r--r--. 1 root root unconfined_u:object_r:rpm_var_lib_t:s0 0 Oct 31 10:14 .rpm.lock ``` Hopefully this solves the issue one and for all now.
I think the selinux-policy somehow forgot to relabel /var/lib/rpm/ in post scriptlet.
*** This bug has been marked as a duplicate of bug 1461313 ***