saved user session not loaded when greeter-hide-users=true

Certainly a tricky problem.

I think the GUI has to be honest, and just add an option "Previous Session" to the session list when running in hidden user list mode. So if that is selected then the greeter doesn't send a session request to the daemon, and the normal .dmrc loading occurs. If the user expliclity selects a session then switch to that one.

How do other greeters handle this?

The process you described in option 2 should be the current behaviour in the daemon, so it's just a modification to the greeter required.

Hmhm, I tried to look at the code but it's a bit hard to exactly know where session is set.

But right now I didn't find any “default_session” (or similar stuff). display->priv->session is set when seat is initialized and then if session is selected in the drop down menu, but then there's no way to know if what we run is the default session or a selected one, and thus if we need to save it to dmrc or not.

In gdm (2.x), afair, when starting the session, is the one to be started is different from the saved one, it'll ask if the user wants to save it. But then I don't know how it handles the “default session”. It might just be that the fallback is done *later* and not earlier. But here, when starting the session, we don't have access to the seat so we can fallback on the seat session default.

Still present in 1.0.1

Still present in 1.2.2.

My understanding was that this was a bug in the greeter, and as such I submitted a patch and bug report on lightdm-gtk-greeter last week:

https://bugs.launchpad.net/lightdm-gtk-greeter/+bug/1031421

I haven't received a response yet, but the patch does fix the problem. However, it does leak the existence of users because it selects the previous session as soon as the username is entered. I'm not sure how serious that really is: modulo XDMCP (which has more serious security problems) this is only exploitable locally, gdm3 also leaks user information in this way, and I think the primary reason to use greeter-hide-users=false isn't privacy but because you have too many users to display in a list. Also, note that the greeter *already* leaks user information with greeter-hide-users=false: if you enter the password incorrectly, the previous session is selected at that point. So this patch should make everything strictly better.

Hello,

since I have been researching this issue for some time already, I've found out that there are several issues related to the handling of the last session and language of a user.

First of all, one needs to know where the information about the last session and language are stored in the filesystem. The traditional way on Unix was to use a file called .dmrc in a user's home directory which is a plain text file containing the name of the default session and language.

Recently, lightdm was modified to use the AccountsService daemon (bug #823718) instead of the traditional .dmrc file storing the information about the default session and language. While this might be a nice idea on single-desktop machines, this change is rather problematic in a networked environment since the AccountsService daemon stores its information locally in /var/lib/AccountsService/users/$USER (bug #1069494).

Furthermore, lightdm has two bugs which prevent proper handling of the last session and last language. In one case, lightdm actually never stores the information about the last language in .dmrc when AccountsService is available and running. However, it always stores the information about the last session in .dmrc, both when AccoutsService is running and when its not (bug #1068853, includes a patch).

And, secondly, lightdm actually never reads the default language from AccountsService, but does read the last language from .dmrc. So this, again, is another inconsistent behavior (bug #1071417, includes a patch).

To make things even worse, lightdm doesn't actually set the LANGUAGE or LANG environment variable to effectively changes the language for any desktop environment or window manager (bug #1019314). The latter bug report contains a work around in the form of an Xsession startup script which reads out the language from AccountsService or dmrc and sets it accordingly before the session is loaded. For the dmrc mechanism to properly work with this workaround when AccountsService is installed, the patch in bug #1068853 has to be applied.

Finally, lightdm should actually provide options to explicitly choose the last session and language (being options in the appropriate selection fields) instead of using the implicit approach proposed in bug #1031421. The proper behavior is actually the way gdm 2.20 handles it (asking whether the new choice of session and language should be default or be used for this session only).

To conclude, there are many bugs which need to be fixed first before lightdm will be fully useful in this regard, being independent of the desktop or window manager being used.

Cheers,

Adrian