This is related to https://bugzilla.redhat.com/show_bug.cgi?id=1746563 , but this is filed directly against selinux-policy and covers only the SELinux denials we're seeing. It seems like there are more problems with g-i-s as it's failing even with SELinux in permissive mode or disabled, but there's definitely a denial breaking something when SELinux is enforcing: Aug 28 11:42:14 localhost-live systemd[991]: selinux: avc: denied { start } for auid=n/a uid=978 gid=976 path="/usr/lib/systemd/user/gnome-session-wayland@.target" cmdline="/usr/libexec/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart --session gnome-initial-setup" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_unit_file_t:s0 tclass=service permissive=0 Aug 28 11:42:14 localhost-live gnome-session[1006]: gnome-session-binary[1006]: WARNING: Falling back to non-systemd startup procedure due to error: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: SELinux policy denies access. Aug 28 11:42:14 localhost-live gnome-session-binary[1006]: WARNING: Falling back to non-systemd startup procedure due to error: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: SELinux policy denies access. so that denial needs to be fixed, I think.
Proposing as a Beta FE as this clearly seems to be blocking GNOME from starting sessions the way it wants to (using systemd), and we shouldn't be relying on its fallback method, I don't think.
Oh, forgot to mention, there are two further denials shortly after this: Aug 28 11:42:16 localhost-live systemd[991]: selinux: avc: denied { start } for auid=n/a uid=978 gid=976 path="/usr/lib/systemd/user/dbus-broker.service" cmdline="/usr/libexec/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart --session gnome-initial-setup" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_unit_file_t:s0 tclass=service permissive=0 Aug 28 11:42:18 localhost-live systemd[991]: selinux: avc: denied { start } for auid=n/a uid=978 gid=976 path="/usr/lib/systemd/user/gnome-session-wayland@.target" cmdline="/usr/libexec/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart --session gnome-initial-setup" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_unit_file_t:s0 tclass=service permissive=0
commit 27d086939296adc126a507eeed20355e6960e1fc (HEAD -> rawhide, origin/rawhide) Author: Lukas Vrabec <lvrabec> Date: Thu Aug 29 14:46:26 2019 +0200 Introduce new type xdm_unit_file_t Create new type for gnome systemd unit files and allow xdm_t SELinux domain to start or get status of these services. rhbz#1746584
commit 880eb445c74aae8552db81082237650415403a47 (HEAD -> rawhide, origin/rawhide) Author: Lukas Vrabec <lvrabec> Date: Thu Aug 29 15:01:03 2019 +0200 Allow xdm_t domain to start dbusd services. rhbz#1746584 commit 106c6216a7e20105d3efcb76e746528b0179c38d (HEAD -> rawhide, origin/rawhide, origin/HEAD) Author: Lukas Vrabec <lvrabec> Date: Thu Aug 29 14:58:10 2019 +0200 Introduce dbusd_unit_file_type Created new type for dbusd systemd unit files and new interface dbusd_systemctl to allow caller domain start,restart,stop, status dbusd services. rhbz#1746584
Discussed during the 2019-09-03 blocker review meeting: [1] The decision to classify this bug as an "AcceptedFreezeException" was made as it is clearly a case of the default Workstation install path not behaving as intended so we ought to fix it. [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-09-03/f31-blocker-review.2019-09-03-16.01.txt
I am in favour of fixing these SELinux policy issues, it is unrelated to the gnome-initial-setup issues from #1746563. i.e. it is not required for proper functionality. gnome-session will do an automatic fall back and everything will work as expected. It looks like the freeze exception acceptance is not affected by this though.
Yeah, the rationale behind the FE is, ideally we want stuff to work on the intended path, not hit fallbacks. And fixing AVCs is just generally something we usually want to do (if nothing else, to avoid notifications popping up).
Lukas, is this fixed in https://bodhi.fedoraproject.org/updates/FEDORA-2019-8169f4e6b7 ? If so, can you mark it as addressing this bug? Thanks!
Sorry for late, reply, I cannot modify pushed updates, moving to CLOSED and adding Fixed version.