gdm won't allow passwordless login

Status changed to 'Confirmed' because the bug affects multiple users.

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1561302

ubiquity-dm is what needs fixing.

But shouldn't a person be able to log out of the live DE and then login w/o a password? I haven't tried recently but I know it was possible at one time with Ubuntu.

Alberto, there may be other related in ubuity-dm, .in particular to the setup of graphics on some systems. However this particular bug is in the gdm greeter itself. Users that log out of the live session, should be able to login again and then to consider users who make a persistent usb and don't set a password.

The sign-in button is not made active until you start typing a password. Which was an intentional change as part of recent auth prompt improvements circa 3.16. We either need to hack around that or better work out the "passwordless" login situation which is supported upstream, but probably patched in Ubuntu.

This also affects the lock screen (although I think it will only activate with <super>+L keypress

at the very least we should set AccountsService.UserPasswordMode.NONE for the live user

The lock screen will obey this, but not sure about the gdm greeter

For the Ubuntu GNOME live DVD/USB in particular, the lack of a passwordless session is a problem because it means that the user has to jump through hoops to try out GNOME Classic. Instead of just logging out, choosing the GNOME Classic session, and logging back in, a user has to figure out that he/she needs to set the Live Session User's password, and *then* log out and choose the GNOME Classic session.

Upstream suggested this might be a problem with the pam configurations

I have tracked this down to the following pam rule being buggy on gdm

auth [success=1 default=ignore] pam_unix.so nullok_secure

Not quite worked out where the bug is, but nullok_secure is an Ubuntu specific argument and fails on gdm, and possibly other !lightdm display managers also.

As documented in pam_unix(8), the nullok_secure option means that null passwords are allowed for this module only when connected via one of the "secure" (that is, generally speaking, "local") ttys listed in /etc/securetty. The tty is not determined directly by pam_unix, but is instead provided to the PAM stack by the calling application setting the PAM_TTY value with pam_set_item(). This is further documented in pam_set_item(3) to be:

       PAM_TTY
           The terminal name: prefixed by /dev/ if it is a device file; for
           graphical, X-based, applications the value for this item should be
           the $DISPLAY variable.

If gdm is not setting the PAM_TTY item, then that's a bug in gdm, not in PAM.

The /etc/securetty list of values is regrettably not comprehensive (because e.g. it doesn't support pattern matching), so if your system has been changed to run gdm on an X display beyond :3, the default value will not work for you. However, I don't see any reason this would occur unless the settings of gdm itself had been changed away from the defaults, and if you've done this you will need to adjust the contents of /etc/securetty to match.

gdm does set PAM_TTY but it seems to be set much later in the pam processing than on lightdm, so basically its not set until after authentication.

I suppose gdm will have to be patched or we somehow override the pam config for gdm only (if that is even possible)

OK, then that is definitely a regression in gdm. The *purpose* of setting PAM_TTY is so that this information is available to pam modules.

Steve, yes, I am fixing it upstream in gdm

gdm will now accept passwordless logins. AccountsService properties are still not set correctly, since casper runs adduser before AccountsService is active. which atleast affects Screen locking on the live session (although only if user explicitly locks screen). I think will need to inject a systemd unit to fix this.

This bug was fixed in the package gdm3 - 3.18.2-1ubuntu2

---------------
gdm3 (3.18.2-1ubuntu2) xenial; urgency=medium

  * debian/patches/fix_pam_nullok_secure.patch: PAM_TTY needs to be set
    before pam_authenticate is called for nullok_secure arg. (LP: #1561302)
  * debian/patches:
    - 0001_gdm_session_set_PAM_TTY.patch,
      0002_gdm_session_require_password.patch: PAM_TTY needs to be set
      before pam_authenticate is called for nullok_secure arg. (LP: #1561302)
    - 0003_support_new_xorg.patch: git patch to support Xorg 1.18

 -- Tim Lunn <email address hidden> Mon, 11 Apr 2016 16:15:50 +1000

J.J, that is going to continue to be a problem even after this is fixed, with passwordless login (once the casper patch lands), you don't have a chance to select the session either, since it skips the password step.

I guess we will just have to mention in the release notes, if you want to try the classic session, set a password first.

This bug was fixed in the package casper - 1.373

---------------
casper (1.373) xenial; urgency=medium

  * scripts/casper-bottom/25adduser:
    - Inject a systemd unit that will call passwd -d to ensure that the
      AccountsService properties (particulary PasswordMode) are correctly
      set for the live session user. This will be ignored on persistent
      USB's (LP: #1561302)

 -- Tim Lunn <email address hidden> Wed, 13 Apr 2016 14:02:44 +1000

"J.J, that is going to continue to be a problem even after this is fixed, with passwordless login (once the casper patch lands), you don't have a chance to select the session either, since it skips the password step."

That's an unfortunate regression, since the previous LTS release of Ubuntu GNOME didn't have that problem.

If that regression can't be fixed, though, a note of that problem definitely should be in the release notes for Ubuntu GNOME's next release.