Greeter shows wrong state after desktop fails to start or crashes
- 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); 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#note-4: "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."
#1 Updated by intrigeri about 3 years ago
The described behaviour is clearly wrong, and should be fixed.
But I'm not sure that the proposed solution is the best one: 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. So even we can surely fix this specific bug the way that's proposed, the resulting behaviour will still be wrong, due to other "bugs". So, I see two options:
- either we start supporting the "logging in >1 times" use case; quite frankly, I'm not thrilled, because I expect that won't be easy, and I'm not aware of many important use cases;
- or we implement better behaviour on failed desktop loading, e.g. pointing the user to possible causes (be it graphics hardware support, lack of memory, corrupted persistent settings) and corresponding solutions. IIRC we already have tickets for some of that.
Until someone is ready to implement some solution to this problem, I suggest this ticket is retitled to describe the problem to solve, rather than a specific solution.