Bug 586825 - Screensaver password prompt delay when resuming on SSSD configured system
Screensaver password prompt delay when resuming on SSSD configured system
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: sssd (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Stephen Gallagher
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 579775
  Show dependency treegraph
 
Reported: 2010-04-28 08:43 EDT by James Laska
Modified: 2013-09-02 02:48 EDT (History)
6 users (show)

See Also:
Fixed In Version: sssd-1.2.0-12.fc13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-01 14:13:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description James Laska 2010-04-28 08:43:31 EDT
Description of problem:

On my laptop, I have SSSD (LDAP ident and Kerberos Auth) configured.  If I suspend my laptop, and resume while no longer connected to physical ethernet, the gnome-screensaver password prompt takes a long while (~60sec) to display and allow login.  Stephen Gallagher explained this is due to the changed network settings between the suspend and resume actions, and sssd times out attempting to use the original network settings.

Version-Release number of selected component (if applicable):

* sssd-1.1.1-3.fc13.x86_64
* gnome-screensaver-2.30.0-1.fc13.x86_64
* NetworkManager-0.8.0-8.git20100426.fc13.x86_64

How reproducible:


Steps to Reproduce:
1. Configure SSSD for LDAP (ident) and Kerberos (auth)
2. Connect system to physical ethernet (no VPN required to access LDAP and Kerberos servers)
3. Login to gnome desktop as a valid user
4. Suspend workstation
5. Unplug from physical ethernet
6. Resume workstation

Actual results:

* It takes a long while (~60sec) to offer passphrase prompt.  There isn't any notification or "busy" icon to indicate the system is attempting to identify the logged in user.
* During this time, I'm also unable to login on any tty consoles.

Expected results:

* Prompted for screensaver passphrase in a reasonable time frame

Additional info:

* IRC converstaion with sgallagh explaining the promblem in more detail ...

08:24:43   sgallagh: jlaska: That actually CAN be related to SSSD, though I don't know about your particular case. (And only if the user you're logged in as is an SSSD user)
08:25:17   sgallagh: jlaska: Basically, if the VPN dropped while you were in screensaver, it may attempt to contact the auth server first, then switch to offline operation once the timeout hits
08:25:41   sgallagh: (or if any other network interruption occurred, but VPN is the common case)
08:26:32   sgallagh: jlaska: The reason is that we always attempt to perform online authentication if the SSSD is marked as operating in online mode, to guarantee that changes on the central server are picked up immediately.
08:27:14   sgallagh: A few people have suggested that screensaver unlocks should happen with cached credentials, but I don't like that because it eliminates our ability to automatically refresh Kerberos tickets when unlocking.
08:31:19   jlaska: sgallagh: ah okay, so you're already well versed in the problem space! :)
08:31:45   jlaska: sgallagh: you're right, I think everytime I see this it's when suspending while connected to physical ethernet, then resuming when no longer connected
08:33:17   sgallagh: jlaska: Something we're looking into doing in the future is registering with NetworkManager to be notified if the network status has changed
08:34:01   sgallagh: jlaska: That way we can tell the backend to go into offline mode immediately, then try to reconnect in 30s or so
08:35:04   jlaska: sgallagh: no worries, thanks for describing the problem space
08:35:28   sgallagh: any time
08:35:46   sgallagh: I don't think we actually have a BZ filed on that, so feel free
Comment 1 Stephen Gallagher 2010-04-28 09:07:33 EDT
Upstream enhancement request opened: https://fedorahosted.org/sssd/ticket/456
Comment 2 Fedora Admin XMLRPC Client 2010-04-28 10:48:51 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 3 James Laska 2010-04-29 16:01:32 EDT
Adding CommonBugs keyword for consideration as an entry on http://fedoraproject.org/wiki/Common_F13_bugs  

Will revisit this issue after review and either 1) to document this issue, or 2) remove the keyword.
Comment 4 Fedora Update System 2010-05-18 14:34:05 EDT
sssd-1.1.92-11.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/sssd-1.1.92-11.fc13
Comment 5 Fedora Update System 2010-05-19 15:15:02 EDT
sssd-1.1.92-11.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update sssd'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/sssd-1.1.92-11.fc13
Comment 6 James Laska 2010-05-25 08:07:53 EDT
Verified with sssd-1.1.92-11 and sssd-1.2.0-12
Comment 7 Fedora Update System 2010-05-27 14:29:02 EDT
sssd-1.2.0-12.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update sssd'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/sssd-1.2.0-12.fc13
Comment 8 Fedora Update System 2010-06-01 14:13:07 EDT
sssd-1.2.0-12.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.