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

[Yves-Alexis Perez]

Hey,

this might be related to #818201 but not completely sure.

Right now, when lightdm starts, the default seat user session is loaded.

Then, if greeter-hide-users=false and one selects a user in the list, its saved settings are loaded, especially the session one (but other settings too). Then, if one selects another session from the dropdown list, this session is loaded. Just before starting the session, the current settings are saved.

When greeter-hide-users=false, nothing replaces the default seat session unless one selects a session in the dropdown menu. Then just before starting the session, current settings are saved.

That means that, in the latter case, the saved user session is never loaded.

I can see two solutions to this:

* load the user settings as soon as the user entered its username: that's not really good since that defeats (one of) the purpose of having greeter-hide-users=true: one can easily check if an user exists and what is the session
* load the default seat setting in a “default_session” field in the DisplayPrivate structure. If someone selects a session in the drop down menu, load it in the session field. Then, just before starting the session:

* if session is set, save it
* if session is not set, load the user setting
* if session is not set and no user setting, use default_session

What do you think?

[Robert Ancell (robert-ancell)]

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?

[Robert Ancell (robert-ancell)]

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.

[Yves-Alexis Perez (corsac)]

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.

[Yves-Alexis Perez (corsac)]

Still present in 1.0.1

[Yves-Alexis Perez (corsac)]

Still present in 1.2.2.

[Andrew Ayer (agwa)]

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.

[John Paul Adrian Glaubitz (glaubitz)]

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