Pam Authenticaion on X41 Thinkpad with Thinkfinger Broken under 8.10 Intrepid

[yositune]

Prior working 8.04 system, upgrade to 8.10 breaks PAM authentication at logins, sudo, and gdm/gnome-screensaver with thinkfinger.

After forced pam-auth-update some improvements but pam upgrade broke with thinkfinger working system.

On command line sudo will result in following

sudo ls
Password or swipe finger: [keyboard entered valid unix password]

[sudo] password for yositune: [keyboard entered valid unix password]

success or failure seems random...

gnome-screensaver fails on all but correct fingerprint scans.
logins will generally succeed or fail with both passwords entered. (I don't run any GDM or other login manager).

---

cat /etc/pam.d/common-auth
#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
# traditional Unix authentication mechanisms.
#
# As of pam 1.0.1-5, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.

auth sufficient pam_thinkfinger.so

# here are the per-package modules (the "Primary" block)
auth [success=1 default=ignore] pam_unix.so nullok_secure
# here's the fallback if no module succeeds
auth requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth required pam_permit.so nullok_secure
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config

----

 cat /etc/pam.d/common-password
#
# /etc/pam.d/common-password - password-related modules common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define the services to be
# used to change user passwords. The default is pam_unix.

# Explanation of pam_unix options:
#
# The "sha512" option enables salted SHA512 passwords. Without this option,
# the default is Unix crypt. Prior releases used the option "md5".
#
# The "obscure" option replaces the old `OBSCURE_CHECKS_ENAB' option in
# login.defs.
#
# See the pam_unix manpage for other options.

# As of pam 1.0.1-5, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
password [success=1 default=ignore] pam_unix.so obscure sha512
# here's the fallback if no module succeeds
password requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password required pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config

[yositune (webpagemail)]

I think this is related to the "return required to authenticate with thinkfinger" bug but I didn't find it (wasn't there one??) so if someone can find it please update and reference.

[yositune (webpagemail)]

 "try_first_pass" wasn't working but after changing order it seem to work more consistently.

If we could flag as configuration for deb an d8.10 upgrade on pam.d I think it's sufficient--otherwise close the bug.

Order should not matter right?? but the below is the working order for me.

auth [success=1 default=ignore] pam_unix.so debug try_first_pass nullok_secure

[Gabe Gorelick (gabegorelick)]

Are you referring to this bug? lp: #311732

[Gabe Gorelick (gabegorelick)]

Sorry, bug didn't get linkified. bug #311732