GNOME Bugzilla – Bug 708997
sssd: lock screen unlocks without a password
Last modified: 2014-03-28 20:07:34 UTC
Description of problem: I am relying on sssd 1.8.6 to authenticate against LDAP and heimdal kerberos servers. This problem only affects the functionality of the lock screen for *remote* users (those who log in locally and are not defined in /etc/passwd, but in the ldap database). Everything works fine for local users. For remote users, also the initial login via gdm works as desired. But, when the screen is locked (manually or automatically), it can be unlocked instantly by any input event (key stroke, mouse movement). Sometimes a single event is not enough and I have to slide the lock screen upwards. In either case, I am never asked for a password. The log files do not indicate any activity from sssd despite the fact I'm on debug_level 7. This problem appeared with gnome-shell 3.10, no problems on 3.8.x. I suspect it has something to do with the recent replacement of the system modal with the gdm login dialog routine. How reproducible: I have not tried any constellation other than my current setup. I am trapped with the outdated sssd 1.8.6, because newer version only compile/work with MIT kerberos, not heimdal. Maybe I should fire up a virtual machine with the latest fedora 20 build and try it there to confirm. Steps to Reproduce: 1. Install gnome 3.10 and sssd 1.8.6. 2. Configure LDAP and kerberos authentication and name resolution via sssd. 3. Log in as remote user. 3. Lock screen manually or wait for it to be locked. 4. Try to unlock. Actual results: Screen unlocks instantly, without password prompt. Expected results: Display of gdm login dialog (like https://raw.github.com/gnome-design-team/gnome-mockups/master/system-lock-login-boot/unlock.png). Unlocking requires a valid password. Renewal of kerberos ticket. Additional info: I am on gentoo linux with systemd 207. pam_sssd is incorporated in system-auth. system-auth is, in turn, included from most of the files in the pam.d folder. I do not know which of these is applying to the lock screen. If it's just gdm-password, then I don't see a problem with the pam configuration, because the gdm login works flawlessly.
I can confirm that the error equally occurs on Fedora 20 with sssd 1.11.0. I used authconfig --update --enablesssd --enablesssdauth to enable sss authentication.
can you put Enable=true in the [debug] section of /etc/gdm/custom.conf restart gdm, reproduce, and then attach the output of journalctl -b -a --full (run as root)
to be sure, if you go to the Privacy panel in control-center, is Screen Lock set to "on" ? what's the output of gsettings list-recursively org.gnome.desktop.screensaver ?
org.gnome.desktop.screensaver color-shading-type 'solid' org.gnome.desktop.screensaver embedded-keyboard-command '' org.gnome.desktop.screensaver embedded-keyboard-enabled false org.gnome.desktop.screensaver idle-activation-enabled true org.gnome.desktop.screensaver lock-delay uint32 0 org.gnome.desktop.screensaver lock-enabled true org.gnome.desktop.screensaver logout-command '' org.gnome.desktop.screensaver logout-delay uint32 7200 org.gnome.desktop.screensaver logout-enabled false org.gnome.desktop.screensaver picture-opacity 100 org.gnome.desktop.screensaver picture-options 'stretched' org.gnome.desktop.screensaver picture-uri 'file:///usr/share/backgrounds/gnome/Sunset.png' org.gnome.desktop.screensaver primary-color '#000000000000' org.gnome.desktop.screensaver secondary-color '#000000000000' org.gnome.desktop.screensaver show-full-name-in-top-bar true org.gnome.desktop.screensaver status-message-enabled true org.gnome.desktop.screensaver user-switch-enabled true
hm, I turned debug on for gdm, but it isn't effective. The only messages I get are Sep 30 18:08:30 gentoo gnome-session[18395]: (gnome-settings-daemon:18439): power-plugin-WARNING **: failed to turn the kbd backlight off: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Method "SetBrightness" with signature "i" on interface "org.freedesktop.UPower.KbdBacklight" doesn't exist Sep 30 18:08:30 gentoo kernel: i2c i2c-3: master_xfer[0] W, addr=0x50, len=1 Sep 30 18:08:30 gentoo kernel: i2c i2c-3: master_xfer[1] R, addr=0x50, len=1 Sep 30 18:08:30 gentoo kernel: i2c i2c-6: master_xfer[0] W, addr=0x50, len=1 Sep 30 18:08:30 gentoo kernel: i2c i2c-6: master_xfer[1] R, addr=0x50, len=1 Sep 30 18:08:30 gentoo kernel: i2c i2c-6: master_xfer[0] W, addr=0x50, len=1 Sep 30 18:08:30 gentoo kernel: i2c i2c-6: master_xfer[1] R, addr=0x50, len=128 Sep 30 18:08:30 gentoo kernel: i2c i2c-6: master_xfer[0] W, addr=0x50, len=1 Sep 30 18:08:30 gentoo kernel: i2c i2c-6: master_xfer[1] R, addr=0x50, len=128
I am also experiencing this issue on my Fedora 20 Alpha system with GNOME 3.10 and SSSD 1.11.1 I turned on the DEBUG logs for SSSD and it appears that the lock screen (gnome-shell?) is not contacting the SSSD's PAM responder for any activity, which either means that it has not called pam_authenticate() or the configured PAM stack does not include pam_sss.so I should note that SSSD was working fine with GNOME 3.8.x on F19 before the upgrade, so I'm reasonably confident it's a GNOME issue and not an SSSD one. Also, /var/log/secure lists no PAM messages when unlocking either, which strongly points towards GNOME not calling pam_authenticate() for some reason.
I debugged this with Stephen a bit on IRC. The problem seems to be caused by the patch that went in for bug 701495: - this._isLocked = true; ... + this._isLocked = user.password_mode != AccountsService.UserPasswordMode.NONE; and accountsservice is incorrectly setting a password mode of NONE for SSSD users because of this code: passwd = NULL;• #ifdef HAVE_SHADOW_H• spent = getspnam (pwent->pw_name);• if (spent)• passwd = spent->sp_pwdp;• #endif• ... if (passwd && passwd[0] != 0) {• mode = PASSWORD_MODE_REGULAR;• }• else {• mode = PASSWORD_MODE_NONE;• }•
I've filed an accountsservice bug here: https://bugs.freedesktop.org/show_bug.cgi?id=70005 Though, I think we should consider reverting the patch for bug 701495. Deciding not to try to authenticate because we think the authentication system will succeed immediately seems like we're getting ahead of ourselves.
Giovanni, should we revert the change that sets isLocked to false based on the password mode? Why can't we just run the PAM conversation and when it returns immediately do the right thing?
will that cause flicker-to-gray or are we starting the pam conversation ahead of time ?
http://cgit.freedesktop.org/accountsservice/commit/?id=631c57790fe79ee70d79522eb1b3e461e2899d82 has solved the issue.
Thanks, I had this on Ubuntu as well, and tried the patch successfully.