login not possible when smartcard is detected pluggned in

This happened to me today. When a smartcard is plugged to USB gdm greeter screen shows username input but while you can enter a username, the password prompt does not appear and it is not possible to login. The journal has this error logged.

gdm-smartcard][1882]: PAM unable to dlopen(/usr/lib/security/pam_pkcs11.so): /usr/lib/security/pam_pkcs11.so: cannot open shared object file: No such file or directory
gdm-smartcard][1882]: PAM adding faulty module: /usr/lib/security/pam_pkcs11.so

This is identical to this upstream bug Gnome Issues 877

It references similar report on debian.

However the work around does not apply to Arch as there is no such file "/etc/gdm3/greeter.dconf-defaults" it seems.

Removing the smartcard (yubikey in my case) and restart gdm and things go back to normal - including last user name and their login icon.

While the bug was first reported a year ago with 45 beta, it has not been resolved.

It is not obvious at all why a user is unable to login when this happens. login just appears completely broken.

added priority3-normal severity4-low statusunconfirmed labels

assigned to @freswa, @toolybird, and @gromit

Long shot.. but if you have the opensc pkg installed, what happens if you downgrade it back to 0.26.0-1?

added statuswaiting-input label and removed statusunconfirmed label

assigned to @heftig and unassigned @freswa, @toolybird, and @gromit

mentioned in issue opensc#2

Since I had not seen this is first time it happened that I am aware it was quite surprising even being an old bug upstream.

I will try older opensc soon as I can but may not be for a day or 2. thanks for suggestion.

Updated: The only difference I see is the presence of /usr/share/p11-kit/modules/opensc.module - so maybe commenting out the 'module: ...' line should be equivalent to installing previous package for testing purposes?

I can confirm that commenting out the 'module' line in /usr/share/p11-kit/modules/opensc.module and problem goes away

So indeed the update of opensc is what triggered the bug happening since it added that file.

Ok, thanks for confirming. It wasn't a long shot after all

Will merge this into opensc#2 which is the root cause. Hopefully @freswa and/or @daandemeyer will sort out a way to fix the breakage.

Course, happy to help. Thanks for taking care of it. And was a good call too - thanks for suggestion.

marked this issue as related to opensc#2

added scoperegression statusconfirmed labels and removed statuswaiting-input label

closed

added resolutionduplicate label

mentioned in commit 4d4ceba1