Description of problem: After logging in, seapplet keeps reappearing despite there is no new problem and setroubleshotd hogs one cpu. The problem goes away after about 10 minutes. Version-Release number of selected component (if applicable): setroubleshoot-server-3.3.23-5.fc33.x86_64 How reproducible: always Steps to Reproduce: 1. have something to generate denial during startup (e.g. bug 1880948) 2. log in Actual results: seapplet keeps reappearing, your cpu fan gets noisy for ~10 minutes Expected results: old problems are not reported again, cpu is idle Additional info: I'm using KDE, if that matters for the frontend ...
Is the SetroubleshootP process consuming the majority of CPU when some SELinux denials happen?
(In reply to Milos Malik from comment #1) > Is the SetroubleshootP process consuming the majority of CPU when some > SELinux denials happen? well, yes, SetroubleshootP seems to appear also, although not on the first place currently, I'm observing the problem - with 3 days uptime, so it doesn't happen only on startup - and top reads: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 689620 setroub+ 20 0 594548 135880 19824 S 66,1 0,4 1:33.79 setroubleshootd 649183 kvolny 20 0 6267292 498896 89468 S 49,8 1,5 106:09.98 QtWebEngineProc 689632 root 20 0 452928 77872 14108 S 31,9 0,2 0:35.58 SetroubleshootP ...
Also run into this after upgrading to Fedora 33 on Thinkpad T470s. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3731 setroub+ 20 0 597432 138432 18956 S 62.5 0.9 5:38.45 setroubleshootd 3742 root 20 0 455192 80364 14044 R 35.5 0.5 2:01.26 SetroubleshootP Running `ausearch -m AVC,USER_AVC -ts recent` returns lots of following messages (like 29298 of them): ---- time->Sun Nov 8 12:33:43 2020 type=AVC msg=audit(1604835223.008:19391): avc: denied { read } for pid=4263 comm="rpm" name="rpmdb.sqlite" dev="dm-1" ino=2622413 scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0 ----
This seems to happen once after an update (e.g. using gnome-software).
Sure is writing a lot of AVC reports about something Event Summary Report ====================== total type ====================== 155541 AVC 895 NETFILTER_CFG 88 SERVICE_STOP 82 SERVICE_START 9 USER_ACCT [ 296.656374] audit: audit_backlog=65 > audit_backlog_limit=64 [ 296.656376] audit: audit_lost=836 audit_rate_limit=0 audit_backlog_limit=64 [ 296.656377] audit: backlog limit exceeded [ 296.656394] audit: audit_backlog=65 > audit_backlog_limit=64 [ 296.656395] audit: audit_lost=837 audit_rate_limit=0 audit_backlog_limit=64 [ 296.656396] audit: backlog limit exceeded [ 296.656436] audit: audit_backlog=65 > audit_backlog_limit=64 [ 296.656437] audit: audit_lost=838 audit_rate_limit=0 audit_backlog_limit=64 [ 296.656438] audit: backlog limit exceeded [ 296.656452] audit: audit_backlog=65 > audit_backlog_limit=64 [ 489.400305] audit_log_start: 32 callbacks suppressed [ 489.400306] audit: audit_backlog=65 > audit_backlog_limit=64 [ 489.400308] audit: audit_lost=850 audit_rate_limit=0 audit_backlog_limit=64 [ 489.400309] audit: backlog limit exceeded [ 531.628966] audit: audit_backlog=65 > audit_backlog_limit=64 [ 531.628968] audit: audit_lost=851 audit_rate_limit=0 audit_backlog_limit=64 [ 531.628969] audit: backlog limit exceeded [ 531.628983] audit: audit_backlog=65 > audit_backlog_limit=64 [ 531.628984] audit: audit_lost=852 audit_rate_limit=0 audit_backlog_limit=64 [ 531.628985] audit: backlog limit exceeded [ 531.629018] audit: audit_backlog=65 > audit_backlog_limit=64 [ 531.629019] audit: audit_lost=853 audit_rate_limit=0 audit_backlog_limit=64 [ 531.629020] audit: backlog limit exceeded [ 531.629032] audit: audit_backlog=65 > audit_backlog_limit=64
All the same as this one, obviously some sort of SELINUX configuration issue with the rpm database after upgrade. 06099566.464:47592): avc: denied { read } for pid=4677 comm="rpm" name="rpmdb.sqlite" dev="sda6" ino=1192312 scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0
To me the condition happens after each reboot.
The problem listed in c#6 has been fixed, please update to the latest selinux-policy package. *** This bug has been marked as a duplicate of bug 1461313 ***
Do restorecon -R /var/lib/rpm