gdm won't allow passwordless login

Bug #1561302 reported by Tim on 2016-03-24
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Ubuntu GNOME
Critical
Unassigned
gdm
Fix Released
Medium
casper (Ubuntu)
Critical
Unassigned
gdm3 (Ubuntu)
Critical
Unassigned

Bug Description

The Live session user does not have a password set, however gdm won't allow login in this case since the "Sign In" button is disabled.

Normally this should be too much of an issue, since the login screen should only be hit on logout from the live session, some people are reporting hitting the gdm login screen on boot due to ubiquity-dm failing to boot.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: gdm3 3.18.2-1ubuntu1
ProcVersionSignature: Ubuntu 4.4.0-15.31-generic 4.4.6
Uname: Linux 4.4.0-15-generic x86_64
ApportVersion: 2.20-0ubuntu3
Architecture: amd64
CurrentDesktop: GNOME
Date: Thu Mar 24 13:55:19 2016
InstallationDate: Installed on 2016-03-23 (0 days ago)
InstallationMedia: Ubuntu-GNOME 16.04 LTS "Xenial Xerus" - Beta amd64 (20160323)
SourcePackage: gdm3
UpgradeStatus: No upgrade log present (probably fresh install)

Tim (darkxst) wrote :
Launchpad Janitor (janitor) wrote :

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

Changed in gdm3 (Ubuntu):
status: New → Confirmed
Ubuntu QA Website (ubuntuqa) wrote :

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

tags: added: iso-testing

ubiquity-dm is what needs fixing.

Changed in gdm3 (Ubuntu):
importance: Undecided → Critical
importance: Critical → High
status: Confirmed → Won't Fix
Erick Brunzell (lbsolost) wrote :

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.

Tim (darkxst) wrote :

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.

Changed in gdm3 (Ubuntu):
status: Won't Fix → Triaged
Tim (darkxst) wrote :

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

Tim (darkxst) on 2016-04-06
Changed in ubuntu-gnome:
milestone: none → xenial
J. J. Ramsey (jjramsey) wrote :

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.

Changed in gdm:
importance: Unknown → Medium
status: Unknown → Confirmed
Tim (darkxst) wrote :

Upstream suggested this might be a problem with the pam configurations

Changed in ubuntu-gnome:
importance: Undecided → High
status: New → Triaged
Tim (darkxst) wrote :

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.

Changed in pam (Ubuntu):
status: New → Triaged
importance: Undecided → Critical
Changed in ubuntu-gnome:
importance: High → Critical
Changed in gdm3 (Ubuntu):
importance: High → Critical
Steve Langasek (vorlon) wrote :

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.

Changed in pam (Ubuntu):
status: Triaged → Invalid
Tim (darkxst) wrote :

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)

Steve Langasek (vorlon) wrote :

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.

Tim (darkxst) wrote :

Steve, yes, I am fixing it upstream in gdm

Tim (darkxst) on 2016-04-11
Changed in gdm3 (Ubuntu):
assignee: nobody → Tim (darkxst)
status: Triaged → In Progress
Tim (darkxst) wrote :

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.

Changed in gdm3 (Ubuntu):
status: In Progress → Fix Committed
Changed in gnome-shell (Ubuntu):
status: New → Invalid
Changed in casper (Ubuntu):
status: New → Triaged
Launchpad Janitor (janitor) wrote :

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

Changed in gdm3 (Ubuntu):
status: Fix Committed → Fix Released
Changed in casper (Ubuntu):
importance: Undecided → Critical
Changed in gnome-shell (Ubuntu):
importance: Undecided → Critical
Tim (darkxst) on 2016-04-13
Changed in gdm3 (Ubuntu):
assignee: Tim (darkxst) → nobody
Tim (darkxst) wrote :
Changed in gdm:
status: Confirmed → Fix Released
no longer affects: pam (Ubuntu)
no longer affects: gnome-shell (Ubuntu)
Tim (darkxst) wrote :

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.

Launchpad Janitor (janitor) wrote :

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

Changed in casper (Ubuntu):
status: Triaged → Fix Released
J. J. Ramsey (jjramsey) wrote :

"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.

Tim (darkxst) on 2016-04-20
Changed in ubuntu-gnome:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.