Bug 586825

Summary: Screensaver password prompt delay when resuming on SSSD configured system
Product: [Fedora] Fedora Reporter: James Laska <jlaska>
Component: sssdAssignee: Stephen Gallagher <sgallagh>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: jgalipea, jhrozek, jturner, sbose, sgallagh, ssorce
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
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 18:13:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 579775    

Description James Laska 2010-04-28 12:43:31 UTC
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 13:07:33 UTC
Upstream enhancement request opened: https://fedorahosted.org/sssd/ticket/456

Comment 2 Fedora Admin XMLRPC Client 2010-04-28 14:48:51 UTC
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 20:01:32 UTC
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 18:34:05 UTC
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 19:15:02 UTC
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 12:07:53 UTC
Verified with sssd-1.1.92-11 and sssd-1.2.0-12

Comment 7 Fedora Update System 2010-05-27 18:29:02 UTC
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 18:13:07 UTC
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.