Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: vscode edit crashed on a freshly upgraded f40 laptop SELinux is preventing abrt-dump-journ from 'write' accesses on the sock_file io.systemd.Machine. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that abrt-dump-journ should be allowed write access on the io.systemd.Machine sock_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-dump-journ' --raw | audit2allow -M my-abrtdumpjourn # semodule -X 300 -i my-abrtdumpjourn.pp Additional Information: Source Context system_u:system_r:abrt_dump_oops_t:s0 Target Context system_u:object_r:systemd_userdbd_runtime_t:s0 Target Objects io.systemd.Machine [ sock_file ] Source abrt-dump-journ Source Path abrt-dump-journ Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-40.13-1.fc40.noarch Local Policy RPM selinux-policy-targeted-40.13-1.fc40.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 6.8.0-0.rc6.49.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Feb 26 18:38:52 UTC 2024 x86_64 Alert Count 8 First Seen 2024-03-09 13:14:50 CET Last Seen 2024-03-09 13:14:50 CET Local ID ec5e0bc5-3e8a-47b3-89e1-91fe22fe85cc Raw Audit Messages type=AVC msg=audit(1709986490.153:394): avc: denied { write } for pid=1485 comm="abrt-dump-journ" name="io.systemd.Machine" dev="tmpfs" ino=2043 scontext=system_u:system_r:abrt_dump_oops_t:s0 tcontext=system_u:object_r:systemd_userdbd_runtime_t:s0 tclass=sock_file permissive=0 Hash: abrt-dump-journ,abrt_dump_oops_t,systemd_userdbd_runtime_t,sock_file,write Version-Release number of selected component: selinux-policy-targeted-40.13-1.fc40.noarch Additional info: reporter: libreport-2.17.15 reason: SELinux is preventing abrt-dump-journ from 'write' accesses on the sock_file io.systemd.Machine. package: selinux-policy-targeted-40.13-1.fc40.noarch component: selinux-policy hashmarkername: setroubleshoot type: libreport kernel: 6.8.0-0.rc6.49.fc40.x86_64 comment: vscode edit crashed on a freshly upgraded f40 laptop component: selinux-policy
Created attachment 2020804 [details] File: description
Created attachment 2020805 [details] File: os_info
SELinux alert browser also shows the following problem that happened at the same time: SELinux is preventing abrt-server from using the nnp_transition access on a process. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that abrt-server should be allowed nnp_transition access on processes labeled abrt_handle_event_t 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-server' --raw | audit2allow -M my-abrtserver # semodule -X 300 -i my-abrtserver.pp Additional Information: Source Context system_u:system_r:abrt_t:s0-s0:c0.c1023 Target Context system_u:system_r:abrt_handle_event_t:s0- s0:c0.c1023 Target Objects Unknown [ process2 ] Source abrt-server Source Path abrt-server Port <Unknown> Host fedora Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-40.13-1.fc40.noarch Local Policy RPM selinux-policy-targeted-40.13-1.fc40.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name fedora Platform Linux fedora 6.8.0-0.rc6.49.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Feb 26 18:38:52 UTC 2024 x86_64 Alert Count 20 First Seen 2024-02-11 18:07:20 CET Last Seen 2024-03-09 13:14:50 CET Local ID 40e027ea-872f-4a5c-88a3-a13996cc6aad Raw Audit Messages type=AVC msg=audit(1709986490.182:395): avc: denied { nnp_transition } for pid=8994 comm="abrt-server" scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:system_r:abrt_handle_event_t:s0-s0:c0.c1023 tclass=process2 permissive=0 Hash: abrt-server,abrt_t,abrt_handle_event_t,process2,nnp_transition
*** This bug has been marked as a duplicate of bug 2266786 ***