Bug 626205

Summary: Unable to unlock screen
Product: [Fedora] Fedora Reporter: Orion Poplawski <orion>
Component: sssdAssignee: Stephen Gallagher <sgallagh>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: awilliam, fedora, jhrozek, jreznik, kevin, ltinkl, mathstuf, rdieter, rnovacek, ry, sbose, sgallagh, smparrish, ssorce, than
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: sssd-1.3.0-35.fc14 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-10-08 16:30:31 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 538277    
Attachments:
Description Flags
sssd_default.log.gz
none
sssd logs tar.gz none

Description Orion Poplawski 2010-08-22 13:50:05 EDT
Description of problem:

I can almost never unlock the screen and need to kill the kscreenlocker process manually.

Version-Release number of selected component (if applicable):
kdebase-workspace-4.5.0-2.fc14.i686
Comment 1 Orion Poplawski 2010-08-27 14:02:28 EDT
Interestingly, if I switch to another VT and bock, it generally works.
Comment 2 Orion Poplawski 2010-10-01 09:43:47 EDT
Created attachment 451016 [details]
sssd_default.log.gz

This may be an sssd issue.  This system uses LDAP but has been away from the home network for a very long time.  It also takes a long time for su - to root to return, even though that is a local file user.
Comment 3 Stephen Gallagher 2010-10-01 09:58:13 EDT
What version of SSSD are you running?

Also, could you include /var/log/sssd/sssd_pam.log ?
Comment 4 Orion Poplawski 2010-10-01 10:58:44 EDT
/var/log/sssd/sssd_pam.log is empty, as is _nss.

sssd-1.3.0-32.fc14.i686
Comment 5 Orion Poplawski 2010-10-01 10:59:58 EDT
Okay, turned on debugging in pam and nss - we'll see what I can get.
Comment 6 Orion Poplawski 2010-10-01 11:17:27 EDT
Created attachment 451034 [details]
sssd logs tar.gz

Here's a session where I tried to log in via kdm but was rejected.

Oct  1 09:14:28 titmouse unix_chkpwd[2587]: password check failed for user (orion)
Oct  1 09:14:28 titmouse kdm: :0[1668]: pam_unix(kdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=  user=orion
Oct  1 09:14:28 titmouse kdm: :0[1668]: pam_sss(kdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=orion
Oct  1 09:14:28 titmouse kdm: :0[1668]: pam_sss(kdm:auth): received for user orion: 4 (System error)
Comment 7 Stephen Gallagher 2010-10-01 11:49:14 EDT
Ok, I need to track it down, but it looks like we're receiving an EINTR response code from somewhere that we aren't handling correctly. If the LDAP server is unreachable, we should be defaulting to cached credentials.

However, because we're getting an unexpected result back, we err on the side of caution and assume that we should throw an error rather than default to cached credentials. We may want to change this as well.
Comment 8 Stephen Gallagher 2010-10-01 13:19:08 EDT
I'm pretty sure I found the bug. Unfortunately, I don't have an environment readily-available to test.

Would you mind trying out this scratch-build and letting me know if it works (and doesn't break anything else)?

http://koji.fedoraproject.org/koji/taskinfo?taskID=2506591
Comment 9 Orion Poplawski 2010-10-01 14:04:50 EDT
That works great!  Any kind of regression you might be particularly worried about that I should test?
Comment 10 Stephen Gallagher 2010-10-01 14:09:41 EDT
Thanks for testing it.

I don't have any real worries, I just always add that rider to any unofficial build I send out :)

I'll get this reviewed and pushed upstream then I'll get an official build for Fedora.
Comment 11 Adam Williamson 2010-10-01 16:05:18 EDT
This was discussed at the 2010-10-01 blocker review meeting, but we cannot decide its blocker status yet as we need more data. Can you please let us know the likely impact of this bug? How many LDAP users are likely to hit it? How bad is the effect (I see a reference above to being unable to login)? How easy is it to work around? Thanks!
Comment 12 Stephen Gallagher 2010-10-04 09:08:14 EDT
(In reply to comment #11)
> This was discussed at the 2010-10-01 blocker review meeting, but we cannot
> decide its blocker status yet as we need more data. Can you please let us know
> the likely impact of this bug? How many LDAP users are likely to hit it? How
> bad is the effect (I see a reference above to being unable to login)? How easy
> is it to work around? Thanks!

Here's the problem. If the system is configured to use LDAP authentication and the system is offline (meaning the LDAP server is not reachable) then there is a bug where, if we receive a pam_authenticate() request without first having received a getpwnam() request for the user, we may not properly detect that we are offline and switch to offline authentication.

This only happens in very rare circumstances (the KDE screensaver being one), because normally a user lookup would be done by e.g. sshd, GDM, etc. before calling the pam_authenticate() function.

So in most cases, it won't prevent initial login, but it may result in an inability to unlock the screensaver.

The fix for this bug was approved upstream this morning and I will build a Fedora package today.
Comment 13 Fedora Update System 2010-10-04 10:02:00 EDT
sssd-1.3.0-35.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/sssd-1.3.0-35.fc13
Comment 14 Fedora Update System 2010-10-04 10:04:03 EDT
sssd-1.3.0-35.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/sssd-1.3.0-35.fc14
Comment 15 Fedora Update System 2010-10-04 14:04:08 EDT
sssd-1.3.0-35.fc14 has been pushed to the Fedora 14 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: https://admin.fedoraproject.org/updates/sssd-1.3.0-35.fc14
Comment 16 Adam Williamson 2010-10-04 15:49:03 EDT
I forgot to mention above, whether to accept this bug as a blocker is a judgment call under the 'most cases' weasel cause of the Alpha criterion:

"In most cases, the installed system must boot to a functional graphical environment without user intervention (see Blocker_Bug_FAQ)"

given the rarity of this bug having a really severe impact (thanks Stephen) I'd vote to make this NTH rather than a blocker.
Comment 17 Adam Williamson 2010-10-04 15:49:27 EDT
s/cause/clause/
Comment 18 Stephen Gallagher 2010-10-04 15:55:47 EDT
Acceptable to have this as a zero-day update instead of on the disc, then?
Comment 19 Orion Poplawski 2010-10-04 16:00:02 EDT
Certainly fine by me.
Comment 20 Adam Williamson 2010-10-04 16:06:58 EDT
that's part of what it means, yeah. however, right now, the fix can still go in final however the bug is categorized (we have not yet hit final freeze), and if the bug was categorized as NTH (nice to have), that would mean we would not actually hold up the release for this bug, but we would take a fix for it through the freeze - into the TC or RC builds.
Comment 21 Fedora Update System 2010-10-08 16:30:10 EDT
sssd-1.3.0-35.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 22 Fedora Update System 2010-10-12 08:48:02 EDT
sssd-1.3.0-35.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.