Greeter shows wrong state after desktop fails to start or crashes
Originally created by @muri on #11587 (Redmine)
Scenarios:
- I start Tails, log in, and GNOME Shell crashes immediately; I’m back in the greeter; if I log in again, GNOME Shell will crash again and I don’t know how to fix, debug or report this problem.
- My GNOME session crashes and I’m back in the Greeter; if I log in again, some things will behave in weird and possibly dangerous ways, and I am not aware of it.
- In the greeter i choose unlock the persistent volume. But i have a corrupt .xsessionrc and the desktop fails to start and returns to greeter. greeter is now back in the default settings, meaning the option for the encrypted persistence is set to ‘NO’. so i expect the corrupted .xsessionrc not to be accessed. But the TailsData partition is still unlocked and mounted, so the desktop session can not start until i reboot and then chose not to enable persistence.
- An attacker crashes the GNOME session and use some X11 cookie somehow to set an administrator password and get root (#11071 (closed)); how feasible this is really does not matter much, as long as the solution to the few other scenarios also prevents this one.
And more generally, we explicitly don’t support logging in a second time (e.g. we hide the “log out” UI) because quite some of our stuff has not been written with this in mind, and is not idempotent.
anonym proposed a solution on #11071 (comment 58420): “Something fairly simple and, I believe, satisfactory would be that when Tails Greeter starts after the first time, it shows a helpful message (”You need to restart Tails“) + shutdown and restart buttons, and do not allow login.”
Related issues
- Related to #11071 (closed)
Edited by muri