Bug 626205

Interestingly, if I switch to another VT and bock, it generally works.

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.

What version of SSSD are you running?

Also, could you include /var/log/sssd/sssd_pam.log ?

/var/log/sssd/sssd_pam.log is empty, as is _nss.

sssd-1.3.0-32.fc14.i686

Okay, turned on debugging in pam and nss - we'll see what I can get.

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)

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.

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

That works great!  Any kind of regression you might be particularly worried about that I should test?

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.

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!

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

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

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

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

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.

s/cause/clause/

Acceptable to have this as a zero-day update instead of on the disc, then?

Certainly fine by me.

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.

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.

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.