Hát ez az, ez történik, és a hiba igazából már csak az, hogy valami furcsa együttállás miatt az igazi gépemen nem fut az autorelabel (ami a selinux-nak rendezi ezeket a fájlokat), ha a .autorelabel fájllal akarom triggerelni, de VM-ben pedig fut.
Ugyanúgy a root partícióba helyeztem el, ugyanolyan fájlrendszer van a gépemen és a VM-ben is. Mindegy.
Az autorelabel=1 kernel paraméter működik viszont.
Szerk1:
Itthagyok egy screenshot-ot a root könyvtárról, amiben ott van a .autorelabel, ez már bebootolva a fizikai gépen: https://imgur.com/a/KKAn6FS
Ezt le kellene törölnie, ha lefut, de ott maradt. Rákeresek, hol fut ez, és megnézem mit csinál.
Szerk2:
Itt van a forrása: /usr/libexec/selinux/selinux-autorelabel
Teleraktam echo-val, és bele sem futott.
Szerk3:
Journalctl-el lekérdeztem a boot-okat:
dlaszlo@desktop:~$ journalctl --list-boots
IDX BOOT ID FIRST ENTRY LAST ENTRY
...
-1 05afd46e597c4056bff6abbc1e05a1a5 Sun 2024-05-05 19:29:35 CEST Sun 2024-05-05 19:46:36 CEST
0 534c0685bc1847e38a0d2376ab18ca1e Sun 2024-05-05 19:46:54 CEST Sun 2024-05-05 20:10:54 CEST
Majd az utolsó boot logját, ami így kezdődik:
dlaszlo@desktop:~$ journalctl -b 534c0685bc1847e38a0d2376ab18ca1e | grep relabel
máj 05 19:47:10 desktop kernel: audit: type=1400 audit(1714931230.434:7): avc: denied { getattr } for pid=1420 comm="selinux-autorel" path="/.autorelabel" dev="dm-0" ino=276358 scontext=system_u:system_r:selinux_autorelabel_generator_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0
máj 05 19:47:11 desktop systemd[1]: selinux-autorelabel-mark.service - Mark the need to relabel after reboot was skipped because of an unmet condition check (ConditionPathExists=!/.autorelabel).
Tehát a 19:47:10-es sor nekem azt jelenti, hogy le akarta kérdezni a .autorelabel fájlt az autorelabeling folyamat (pid: 1420), de nem volt hozzá jogosultsága... Miért? A fájl továbbra is ott van rwrwrw jogosultsággal:
dlaszlo@desktop:~$ ls -la /
összesen 20
dr-xr-xr-x. 1 root root 182 máj 5 19.28 .
dr-xr-xr-x. 1 root root 182 máj 5 19.28 ..
dr-xr-xr-x. 1 root root 0 jan 24 01.00 afs
-rw-rw-rw-. 1 root root 0 máj 5 19.28 .autorelabel
lrwxrwxrwx. 1 root root 7 jan 24 01.00 bin -> usr/bin
...De ez magyarázza, hogy miért nem futott le az autorelabel folyamat.
Szerk4:
Megoldva: Hozzáadtam az enforcing=0 kernel paramétert a következő bootoláskor (ez a permissive mód kell, úgy látszik, és valami doskiban is olvastam), és így lefutott az autorelabel! Szépen törölte is a /.autorelabel fájlt
Fogalmam sincs, hogy VM alatt miért működött default.