Created attachment 1805361 [details] coredump file of systemd and audit log Description of problem: Systemd coredump and all services depends systemd can't work Version-Release number of selected component (if applicable): systemd-248.5-1.fc34.x86_64 How reproducible: I don't know a exactly way to produce it. This first hapend two days ago when I run a docker command: docker run -it -v `pwd`:/workspace ubuntu /bin/sh. Then the message tell me "systemd[1]: Freezing execution". Then I inspect it by # cat /var/log/audit/audit.log| audit2why type=AVC msg=audit(1626864773.201:998): avc: denied { prog_run } for pid=3877 comm="runc" scontext=system_u:system_r:container_runtime_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=bpf permissive=1 Was caused by: Unknown - would be allowed by active policy Possible mismatch between this policy and the one under which the audit message was generated. Possible mismatch between current in-memory boolean settings vs. permanent ones. type=AVC msg=audit(1626925225.222:1256): avc: denied { write } for pid=13721 comm="systemd-coredum" name="core_pattern" dev="proc" ino=15477 scontext=system_u:system_r:systemd_coredump_t:s0 tcontext=system_u:object_r:usermodehelper_t:s0 tclass=file permissive=0 Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access. type=AVC msg=audit(1627171936.307:432): avc: denied { write } for pid=4673 comm="systemd-coredum" name="core_pattern" dev="proc" ino=335 scontext=system_u:system_r:systemd_coredump_t:s0 tcontext=system_u:object_r:usermodehelper_t:s0 tclass=file permissive=0 Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access. First type error should be fixed by me, but I don't know why it produced always. The second has no fixed. # cat /etc/selinux/custom/docker.te module docker 1.0; require { type container_runtime_t; type init_t; class bpf prog_run; } #============= container_runtime_t ============== allow container_runtime_t init_t:bpf prog_run; Then I can find a coredump file just produced: # LANG=en.US_UTF-8 l /var/lib/systemd/coredump drwxr-xr-x. 2 root root 169 Jul 25 08:33 . drwxr-xr-x. 11 root root 157 Jul 20 21:31 .. -rw-r-----. 1 root root 752K Jul 25 08:12 core.systemd.0.9c98606c191b4f02bcea61747aec80f9.4672.1627171936000000.zst -rw-r-----. 1 root root 816K Jul 22 11:40 core.systemd.0.dbe468c7311b43cbbf2f7ef74b855d93.13720.1626925225000000.zst
This bug can be solved by : ``` xxx.te module custom 1.0; require { type container_runtime_t; type systemd_coredump_t; type usermodehelper_t; type init_t; class bpf prog_run; class file write; } #============= container_runtime_t ============== #!!!! This avc is allowed in the current policy allow container_runtime_t init_t:bpf prog_run; #============= systemd_coredump_t ============== allow systemd_coredump_t usermodehelper_t:file write; ```
About the crash of systemd itself: systemd-248.5-1.fc34.x86_64 was buggy. Please upgrade to systemd-248.6-1.fc34.x86_64. As for the selinux denials: you might want to file a bug against the selinux policy package. But I'd just ignore it… Systemd doesn't crash that often ;) *** This bug has been marked as a duplicate of bug 1984651 ***