Got this localized message from throbleshooter SELinux powstrzymuje /usr/lib/systemd/systemd-resolved przed dostępem watch w katalog /. ***** Wtyczka catchall_labels (83.8 zaufania) sugeruje ******************** Aby zezwolić systemd-resolved na dostęp watch w directory Wtedy należy zmienić etykietę / Wykonać # semanage fcontext -a -t TYP_PLIKU '/', gdzie TYP_PLIKU jest jednym z poniższych: init_var_run_t, root_t, system_dbusd_var_run_t, systemd_networkd_var_run_t, systemd_resolved_var_run_t, tmpfs_t, var_run_t. Następnie należy wykonać polecenie: restorecon -v '/' ***** Wtyczka catchall (17.1 zaufania) sugeruje *************************** Aby systemd-resolved powinno mieć domyślnie watch dostęp do directory. Wtedy proszę to zgłosić jako błąd. Można utworzyć lokalny moduł polityki, aby umożliwić ten dostęp. Wykonać można tymczasowo zezwolić na ten dostęp wykonując polecenia: # ausearch -c 'systemd-resolve' --raw | audit2allow -M my-systemdresolve # semodule -X 300 -i my-systemdresolve.pp Dodatkowe informacje: Kontekst źródłowy system_u:system_r:systemd_resolved_t:s0 Kontekst docelowy system_u:object_r:usr_t:s0 Obiekty docelowe / [ dir ] Źródło systemd-resolve Ścieżka źródłowa /usr/lib/systemd/systemd-resolved Port <Nieznane> Komputer jcubic Źródłowe pakiety RPM systemd-resolved-251.14-2.fc37.x86_64 Docelowe pakiety RPM Pakiet RPM polityki SELinuksa selinux-policy-targeted-37.19-1.fc37.noarch Lokalny pakiet RPM polityki selinux-policy-targeted-37.19-1.fc37.noarch SELinux jest włączony True Typ polityki targeted Tryb wymuszania Permissive Nazwa komputera jcubic Platforma Linux jcubic 6.2.10-200.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Apr 6 23:30:41 UTC 2023 x86_64 x86_64 Liczba alarmów 1 Po raz pierwszy 2023-04-21 18:25:41 CEST Po raz ostatni 2023-04-21 18:25:41 CEST Lokalny identyfikator 35a097e2-a84b-4894-9c8a-1cb6d62c610b Surowe komunikaty audytu type=AVC msg=audit(1682094341.26:162): avc: denied { watch } for pid=927 comm="systemd-resolve" path="/" dev="sda4" ino=2 scontext=system_u:system_r:systemd_resolved_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=dir permissive=1 type=SYSCALL msg=audit(1682094341.26:162): arch=x86_64 syscall=inotify_add_watch success=yes exit=EPERM a0=f a1=7f201a2a4962 a2=180 a3=7ffe11d5d6c4 items=1 ppid=1 pid=927 auid=4294967295 uid=193 gid=193 euid=193 suid=193 fsuid=193 egid=193 sgid=193 fsgid=193 tty=(none) ses=4294967295 comm=systemd-resolve exe=/usr/lib/systemd/systemd-resolved subj=system_u:system_r:systemd_resolved_t:s0 key=(null) type=CWD msg=audit(1682094341.26:162): cwd=/ type=PATH msg=audit(1682094341.26:162): item=0 name=/ inode=2 dev=08:04 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:usr_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 Hash: systemd-resolve,systemd_resolved_t,usr_t,dir,watch Reproducible: Didn't try I have no idea what trigger this, after booting got this SELinux error.
Hi Jakub, It would be nice ifwe knew howto reproduce the issue. Still, can you gather some more details? What filesystem is on sda4? At which moment this issue happened? Can you pair the audit event with some journal logs data?
Sorry I have no idea, I usually run my system for a long time, I've turned it off and run again after one day and got this in my notifications.
As no new information appeared during the past weeks, we are going to close this bug. If you need to pursue this matter further, feel free to reopen this bug and attach the needed information.