Bug#1051785: gdm3 won't allow logins when a smarcard with a x.509 credential is plugged in

[Simon McVittie]

On Fri, 15 Sep 2023 at 16:05:24 +0000, Harlan Lieberman-Berg wrote:
> I've gotten bitten by this one too, I'm afraid, this time in Debian testing.
> 
> Potentially interestingly, though I do have a PKCS#11 token inserted,
> it has no certificates on it.

If you run as root

    update-alternatives --set gdm-smartcard /etc/pam.d/gdm-smartcard-sssd-or-password

does that restore previous functionality?

If I understand the situation correctly, when gdm detects the presence of
a smartcard, it switches from its default gdm-password PAM profile to
gdm-smartcard, which is an alias for either gdm-smartcard-pkcs11-exclusive,
gdm-smartcard-sssd-exclusive or gdm-smartcard-sssd-or-password.

However, in the two -exclusive profiles, "exclusive" means "password
login is not allowed, only smartcard login can work" - which obviously
isn't right if you don't have smartcard-related PAM modules installed,
or if you haven't configured any {smartcard -> user account} mappings.

If my understanding is correct, then I think
gdm-smartcard-sssd-or-password would be a better default, unless
there are factors here that I'm not seeing. Sysadmins could still set
the alternative to point to gdm-smartcard-sssd-exclusive for a more
locked-down system, but only after ensuring that smartcard-based login
has been configured and actually works!

(Explicitly cc'ing Marco here since he seems to be the expert on gdm's
interactions with PAM, and the one driving the smartcard handling
enhancements that seem to have triggered this regression.)

    smcv