GNOME Bugzilla – Bug 359779
Unable to unlock when using pam_ccreds
Last modified: 2006-10-21 00:45:25 UTC
Forwarded from: https://launchpad.net/distros/ubuntu/+source/gnome-screensaver/+bug/43465 Default install of gnome-screensaver is unable to unlock on my system. I am running a custom pam setup which works for every other app I use. xscreensaver used to have a similar problem. Could be a problem with pam_krb5 or pam_ccreds, actually. Not sure. auth [default=die success=done authinfo_unavail=reset] pam_unix.so auth [default=die success=1 service_err=reset auth_err=reset] pam_krb5.so use_first_pass debug forwardable auth [default=die success=done] pam_ccreds.so action=validate use_first_pass auth [default=done] pam_ccreds.so action=store use_first_pass account [default=die success=1 authinfo_unavail=reset] pam_unix.so account [default=die success=ok] pam_krb5.so account required session required pam_unix.so session optional pam_foreground.so -- tjaalton: -note that pam_krb5 is likely not to blame, since it is working just fine for quite some time now. Pam_ccreds ("cached credentials") might need to have some sort of special support from g-s like pam_krb5 did when it didn't refresh the user ticket...
Just looked at the pam_ccreds source and it doesn't seem to use any environment variables so that isn't it. However, it does seem to prompt for input. Can the reporter try using 2.16? Not sure g-s 2.14 really supports anything but pam_unix input really...
I am the original reporter. I have tried 2.16, with the same results. pam_ccreds is used something like this: auth [default=die success=1 service_err=reset auth_err=reset] pam_krb5.so auth [default=die success=done] pam_ccreds.so action=validate use_first_pass auth [default=done] pam_ccreds.so action=store use_first_pass The idea is, depending on the output of pam_krb5, one or the other pam_ccreds action is invoked. If pam_krb5 suceeds, pam_ccreds is invoked with action=store. This causes it to store the hash of the password in a local cache directory. It then "default=done", which basically returns suceess to the asking program. If pam_krb5 fails, for any reasons (in my case, because it doesn't respect the difference between auth_err and service_err, yet), the pam status is reset, and pam moves onto the action=validate step. pam_ccreds takes the entered password (use_first_pass), so it doesn't prompt, and validates it against the local hash. It then either kills the pam chain or succeeds. It should never actually prompt for creds. I don't believe it even supports it.
Ok, let's focus on 2.16 then. Can you post the output of test-passwd that is included in the g-s sources? Ok, from the sources it looks like pam_ccred only falls through to _pam_sm_interact() if the try_first_pass is used instead of use_first_pass. So, that isn't it.
actually, I think this is in fact a pam_ccreds-issue, see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=151914 the problem is that the cached database is only readable by root, so some trickery needs to be done. This bug could then be closed as NOTGNOME :)
I agree. Looks like PADL has a bug for it, I will start tracking that.
Sorry about this. Reopening. I have applied RedHat's patch on ccreds, looks okay. Still doesn't work. I have located test-passwd and been trying to divine it's intentions... from what I can tell pam_ccreds is *never* invoked, and I'm not sure why. Oct 20 19:35:32 kyoto test-passwd: (pam_unix) authentication failure; logname= uid=262715738 euid=262715738 tty=:0.0 ruser= rhost= user=wasabi O That is the pam_unix message being sent to syslog. Auth failure. That's not exactly true. pam_unix should be returning an AUTHINFO_UNAVAIL status for my account, because my account does not exist in NSS shadow. Accordingly, PAM should be sending authinfo_unavail=reset to CONTINUE PROCESSING. However, processing is not continued. At least nothing else outputs log messages, and sys/ltrace show no other modules being processed. Is there any furthur way to debug this using test-passwd? Perhaps have it output a line by line progress of it's path through PAM? Is it possible pam_unix returns auth failure when non-root? If true, would that make it a pam_unix problem? :)
Haha. This seems to be correct! On forcing pam_unix to reset in the default case test-passwd moves through both krb5 and ccreds successfully. This is a bit unfortunate!