Delayed Autologin broken by User List in Greeter

[foxy123]

There is no way to set up time-out before autologin so other users could cancel the default login and log in themselves. I tried an option
autologin-user-timeout=10

but it does not work.

[i (iiiiii-deactivatedaccount)]

lightdm.i686 1.4.0-2.fc18 (Fedora)

Auto-login works if time-out is set to 0 (zero) otherwise it fails. Do you need logs or other info?

[Paiiou (paiiou)]

Tht autologin-user-timeout is a very interesting characteristic.
The defect also affects the distributions) Mageia.

Can you take care of it?

[Hb (hbb)]

Automatic Login fails reproducibly if autologin-user-timeout is set to something other than 0 (zero).

If not timeout is set, LightDM creates an "user session" after starting a seat. See the following comment for this log file.

With a delay set a "greeter session" is created, see the attached log file. Then after the delay the internal authorization for the auto-login-user seems to be successful. And that was it, nothing happens any more.

System is a brand new Lubuntu 14.04.2 installation. My /etc/lightdm/lightdm.conf is:
[SeatDefaults]
autologin-user=family
autologin-user-timeout=4
autologin-session=lightdm-autologin
user-session=Lubuntu
greeter-session=lightdm-gtk-greeter

[Hb (hbb)]

Delayed Autologin works here now after setting the option "greeter-hide-users=true".

Conclusion is that automatic login without a timeout works always because the user list isn't asked for. When a timeout is set only suppressing the user list gives a working auto login.

I got the hint from http://lists.freedesktop.org/archives/lightdm/2014-July/000639.html .

[Laércio de Sousa (lbssousa)]

I can confirm this with lightdm-gtk-greeter at Xubuntu 15.04.

I have a 2-seat computer and lightdm configured to autologin as a given user (also applies for guest) on both seats. If the user configured for autologin on a given seat is selected in user list when timeout reaches 0, it won't autologin. However, if I change the user selected before timeout reaches 0, autologin works as expected.

Not sure if it also happens for unity-greeter.

[Hb (hbb)]

> ..., if I change the user selected before timeout reaches 0, autologin works as expected.

The current "Works as expected" is at least one other bug:

If the selection in the user list is changed but no password entered, the invisible count down does not stop. After the delay the predetermined auto-login user is logged in. That is wrong, any human action should stop the countdown. Otherwise the human user is forced to type in his super secure 24 digit long password within the delay time. This is bug 1121660.

[Hb (hbb)]

It gets more interesting. The setting is
[SeatDefaults]
autologin-user=family
autologin-user-timeout=30
greeter-hide-users=true

This allows to type in the other username and the password The other user account is now started. After some inactivity time Light Locker locks up the screen. If activated again LightDM opens the initial autologin=user. The system now has two sessions with different users.

Hb

[Laércio de Sousa (lbssousa)]

I guess I may have found a better explanation about this bug.

Whenever a user is switched in greeter, i.e. a new user selection is made in greeter's user list, LightDM immediately sets its PAM authentication service to either "manual" (set by option [Seat*]/pam-service) or "autologin" (set by option [Seat*]/pam-autologin-service).

When autologin timeout expires, user currently selected in greeter's user list is switched to that one set in [Seat*]/autologin-user option, which in turn sets its PAM authentication service to "autologin", and then performs the login.

However, if the user selected in greeter's user list matches that one set in [Seat*]/autologin-user in the moment autologin timeout expires, then no user switching is performed, and no autologin is triggered.

If my assumption is right, maybe we can fix the bug by forcing lightdm to "switch user to itself" when autologin timeout expires.

Robert, what do you think about it?

[Laércio de Sousa (lbssousa)]

I've did a quick test with 3 greeters in Xubuntu 15.04. The results are the following:

* unity-greeter: timed autologin works always

* lightdm-gtk-greeter: timed autologin fails if configured user is currently selected in user list at the moment timeout expires, but it does work otherwise.

* lightdm-kde-greeter: timed autologin doesn't work at all

So, this bug is much more likely to be related to the greeters than to lightdm itself. However, what I did is a "dirty" test (all greeters installed in a same Ubuntu flavour), so I may have introduced some misconfiguration that may lead to the problems related here. A more reliable result may require that each greeter be tested on its proper Ubuntu flavour with default settings (i.e. Ubuntu with unity-greeter, Kubuntu with lightdm-kde-greeter, etc.).

[Laércio de Sousa (lbssousa)]

I guess I can trace out the problem now:

1. When I change the selected user in lightdm-gtk-greeter user list, function set_displayed_user() is called.

2. lightdm-gtk-greeter's function set_displayed_user(), in turn, calls start_authentication(), which then calls lightdm function lightdm_greeter_authenticate() (or lightdm_greeter_authenticate_as_guest(), if guest login is selected).

3. When autologin timeout expires, greeter calls lightdm_greeter_authenticate_autologin(), which, in turn, calls the same suitable lightdm_greeter_authenticate{,_as_guest}() function as before.

In the end, lightdm_greeter_authenticate{,_as_guest}() is called twice for the same user, and maybe the second call is ignored by lightdm. If this is right, some possible solutions are:

A. In lightdm-gtk-greeter's function set_displayed_user(), check first if selected user matches configured autologin one, and don't call start_authentication() immediately if they match, but only when login button is clicked.

B. In lightdm-gtk-greeters's function start_authentication(), check first if given username matches configured autologin one, and don't call lightdm_greeter_authenticate{,_as_guest}() if they match.

C. In lightdm's function lightdm_greeter_authenticate{,_as_guest}(), allow somehow that a second call for the same user overrides the first call, specially if second call is of autologin kind, and first one is of manual kind.

[Laércio de Sousa (lbssousa)]

I'm pretty close to address this problem. I've changed lightdm-gtk-greeter.c main code, introducing a new autologin_cb() callback function to be connected to signal "autologin-timeout-expired". Here is my autologin_cb() latest implementation:

static void
autologin_cb (LightDMGreeter *greeter)
{
    if (lightdm_greeter_get_is_authenticated (greeter))
    {
        /* Autologin user is likely to be aready selected in user list.
           If autologin-guest is enabled, just assume "*guest" is selected and
           there are no mistakes in lightdm.conf (e.g. setting both autologin-guest
           and autologin-user). */
        if (lightdm_greeter_get_autologin_guest_hint (greeter))
            start_session ();
        else if (lightdm_greeter_get_autologin_user_hint (greeter))
        {
            if (g_strcmp0 (lightdm_greeter_get_authentication_user (greeter),
                           lightdm_greeter_get_autologin_user_hint (greeter)) == 0)
                start_session ();
            else
            {
                /* Worst case: autologin-user is set in lightdm.conf, but "*guest"
                   is currently selected. Let's start a new authentication for
                   autologin user and hope for the best. */
                start_authentication (lightdm_greeter_get_autologin_user_hint (greeter));

                /* FIXME: wait somehow until new authentication is completed
                          before starting autologin user session. */

                /* In this current state, the following call will fail. Autologin user
                   is already authenticated, but user still needs to click on login
                   button to start session. */
                start_session ();
            }
        }
    }
    else
        lightdm_greeter_authenticate_autologin (greeter);
}

I've tested this function in all possible scenarios, and it only fails in one case, namely: if autologin-user is set, but "Guest session" is selected when autologin timeout expires. In this case, autologin user session doesn't start automatically, but it does start correctly when I click on login button after timeout, even if "Guest session" is shown in user list.

[Laércio de Sousa (lbssousa)]

Never mind! I've just found a VERY MUCH SIMPLER approach to solve this issue.

The key point is the global boolean variable "prompted". When lightdm-gtk-greeter calls lightdm_greeter_authenticate_autologin(), it waits for a signal and then calls function authentication_complete_cb(), which, in turn, starts user session. However, it only does it if "prompted" is set to TRUE, which is not the case for autologin.

So, all we have to do in my proposed autologin_cb() function is setting "prompted" to TRUE while calling lightdm_greeter_authenticate_autologin(). Here is my very smaller autologin_cb() implementation:

static void
autologin_cb (LightDMGreeter *greeter)
{
    prompted = TRUE;
    lightdm_greeter_authenticate_autologin (greeter);
}

I've tested it, and now it works in all possible scenarios.

[Laércio de Sousa (lbssousa)]

I've made some improvements in my timed autologin callback function proposal, merging the simple implementation right above with the other ones I've written before. You can see the final result in my merge proposal:

https://code.launchpad.net/~lbssousa/lightdm-gtk-greeter/fix-timed-autologin/+merge/257425

Basically, current implementation differs from that simple one by doing some additional checks in order to avoid authenticating the same user twice (when it's selected in user list, and when lighdm_greeter_authenticate_autologin() is caled).