GNOME Bugzilla – Bug 666860
When switching user, session is not properly locked (with LightDM)
Last modified: 2019-11-03 11:17:50 UTC
Original bug here: https://bugs.launchpad.net/gnome-panel/+bug/904006 Tested on Ubuntu 11.10: - Log in a gnome-classic session - Select "Switch User" in the top-right menu (you are now on lightdm, your former session is supposed to be protected by a password) - Switch to a random TTY - Switch back to the graphical session: you are now in your first session, without entering any password. This seems to work only with the combination of gnome-classic (with or without effects) and lightdm. No problem with Unity or Gnome-Shell with lightdm. With GDM3, no problem with gnome-classic. According to Ubuntu devs, this is more likely to be a gnome-panel issue: "well it doesn't mean it's not a bug in the gnome fallback session, it should not rely on the login manager to lock the screen since there is no garanty the one you use will do that for you, under unity the indicator do lock the screen before calling the user switching"
Does GNOME Classic mean the Fallback Mode of GNOME3? Asking as I really don't know Ubuntu's (re)naming policy, and classic to me implies GNOME 2.
Yes, this is indeed the Fallback mode.
Looks like an issue in gnome-session, not in gnome-panel…
Nicolas: Is that still an issue in recent versions?
André: Not sure if it's actually the same than 8 years ago (!), but a similar bug is at least still present. Step to reproduce: * On a a fresh install of the latest Ubuntu 19.10 snapshot (Gnome-Shell 3.34.0, Gnome-session 3.34.1) * Install the lightdm package, reboot to verify it is indeed used instead of GDM * After loging-in on Gnome-Shell, lock the screen * On the LightDM lock screen, switch to TTY 1 then back to 7 * No password is asked and I'm now back, fully logged-in, in the session. Not that, contrary to the original bug description, this was here reproduced with the default Gnome Shell session.
So maybe this should indeed be moved to Gnome-Session, as I think gnome-panel is no longer involved at this point. Should I open a new bug on Gitlab or is there a more automated way to move things around?
It's possible to import tasks but given that this one is eight years old a new task with up-to-date steps in Gitlab would be welcome.
Ok, reported against gnome-session here: https://gitlab.gnome.org/GNOME/gnome-session/issues/39
Thanks. Closing this task as obsolete.