pam_unix returns incorrect return value when not run as root

[Jerome Haltom]

In attempting to fix bug #43465 I have stumbled across this additional issue.

My common-auth file follows:

auth [default=die success=done authinfo_unavail=reset] pam_unix.so debug
auth [default=die success=1 service_err=reset auth_err=die] 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

The basic idea here is that pam_unix should return success only when it is successful, and the process should exit successfully. If pam_unix returns "authinfo_unavail", which basically indicates that no password is assigned to this user locally or in shadow, the stack should proceed to the next module. Any other exit value, such as auth_err, should result in immediate termination.

When run with login, ssh, gdm, and most other pam applications, this works exactly as expected.

When run from gnome-screensaver, while trying to unlock the screen, this does not work.

The difference is that gnome-screensaver does not run as root. I suspect this improperly alters the exit code. Even when run as non-root, the exit code should still be the same, there is no local shadow entry for this user and he does not appear in /etc/passwd. He is delivered by nss_ldap.

This bug is blocking the network-authentication spec.

[Corey Burger (corey.burger)]

This is confirmed

[Morten Siebuhr (msiebuhr)]

I've hit this bug when developing an application validating users using PAM; even when you make a /etc/pam.d/something file that uses the dummty "allow everything" module, PAM insists on trying to read /etc/shadow for some reason. If and when you run the application as root (or as a user in the "shadow"-group) no such problem exists.

The postgresql-folks seem to have hit this as well: http://archives.postgresql.org/pgsql-advocacy/2003-05/msg00058.php

(I did cook up some minimal files using Python-PAM to illustrate this, but unfortunately I got a little over-zealous cleaning up my code last week. No VCS-checkins as well. Æv.)

[Steve Langasek (vorlon)]

Jerome, could you check whether this is still an issue with pam 1.0.1, now in intrepid? I believe that a recent code refactor upstream means that the return values will be the same when running as root or as a user.

msiebuhr, you appear to be describing a separate issue. PAM does *not* read /etc/shadow except when configured to use the pam_unix module, so it sounds like you have a configuration error.

[Steve Langasek (vorlon)]

Jerome, I'm sure you're out there, I just saw you on #multiarch ;) Can you please comment whether this is still an issue with current versions of pam_unix?

[Launchpad Janitor (janitor)]

[Expired for pam (Ubuntu) because there has been no activity for 60 days.]

[uwe (maabdulhaq)]

Hello,

I'm using oneiric 11.10 ; i face the same issue, logins work fine, but gnome-screensaver does not; in the auth logs i get a message saying:

Aug 20 20:31:37 hostname unix_chkpwd[17080]: check pass; user unknown
Aug 20 20:31:40 hostname unix_chkpwd[17081]: check pass; user unknown
Aug 20 20:31:40 hostname unix_chkpwd[17081]: password check failed for user (usernameX)
Aug 20 20:31:40 hostname gnome-screensaver-dialog: pam_unix(gnome-screensaver:auth): authentication failure; logname= uid=10013 euid=10013 tty=:0.0 ruser= rhost= user=usernameX
Aug 20 20:31:51hostname ccreds_chkpwd[17095]: error reading cached credentials