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

[Paul Tagliamonte]

Subject: gdm3 won't allow logins when a smarcard with a x.509 credential is plugged in
Package: gdm3
Version: 45~beta-1
Severity: important
thanks

Hey GNOME maintainers,

I upgraded my sid system, and post-upgrade gdm3 isn't showing my face
when I reboot, and entering my username causes it to loop back to
username entry again (no password prompt). After some help from smcv, I
narrowed down the issue to the interactions between my smartcard
development tools installed locally and gdm3.

The journal shows the following output:

| Sep 12 10:18:47 nyx gdm-launch-environment][1851]: pam_unix(gdm-launch-environment:session): session opened for user Debian-gdm(uid=116) by (uid=0)
| Sep 12 10:18:49 nyx gdm-smartcard][2749]: PAM unable to dlopen(pam_sss.so): /lib/security/pam_sss.so: cannot open shared object file: No such file or directory
| Sep 12 10:18:49 nyx gdm-smartcard][2749]: PAM adding faulty module: pam_sss.so
| Sep 12 10:19:02 nyx gdm-smartcard][2749]: gkr-pam: no password is available for user
| Sep 12 10:19:02 nyx gdm-smartcard][3505]: PAM unable to dlopen(pam_sss.so): /lib/security/pam_sss.so: cannot open shared object file: No such file or directory
| Sep 12 10:19:02 nyx gdm-smartcard][3505]: PAM adding faulty module: pam_sss.so
| Sep 12 10:19:03 nyx gdm-smartcard][3505]: gkr-pam: no password is available for user
| Sep 12 10:19:03 nyx gdm-smartcard][3512]: PAM unable to dlopen(pam_sss.so): /lib/security/pam_sss.so: cannot open shared object file: No such file or directory
| Sep 12 10:19:03 nyx gdm-smartcard][3512]: PAM adding faulty module: pam_sss.so
| Sep 12 10:19:33 nyx gdm-smartcard][4045]: PAM unable to dlopen(pam_sss.so): /lib/security/pam_sss.so: cannot open shared object file: No such file or directory
| Sep 12 10:19:33 nyx gdm-smartcard][4045]: PAM adding faulty module: pam_sss.so
| Sep 12 10:19:34 nyx gdm-smartcard][4045]: gkr-pam: no password is available for user
| Sep 12 10:19:34 nyx gdm-smartcard][4237]: PAM unable to dlopen(pam_sss.so): /lib/security/pam_sss.so: cannot open shared object file: No such file or directory
| Sep 12 10:19:34 nyx gdm-smartcard][4237]: PAM adding faulty module: pam_sss.so

(I do not have libpam-sss installed - after I got this error I installed
it to see if I could unlock myself, but it didn't do much and I purged
it again).

I have not configured my machine to use gdm-smartcard (nor do I want
to); but I do have a lot of smartcard stuff installed due to other hobby
work. I have NSS set up to talk with OpenSC, but that's only for TLS
keying material via GNOME, not system login.

When I unplugged my Yubikey which is both WebAuthN and a x.509
Smartcard, I was able to log in as usual.

My hunch is that I believe gdm-smartcard thinks it's supposed to kick
into gear and authenticate my smartcard, but it isn't configured to do
so (heck, it hasn't been told how to match my UPN/Email
SAN/Subject/Serial to UID, nor an x.509 CA to use for user
authentication). However, it kicking into gear has kicked me out of my
ability to login :)

I suspect the fix here is to explicitly toggle on gdm-smartcard when it's
properly configured, rather than implicitly running when the right deps
are installed and an x509 cert is found on an OpenSC token when it can't
properly authenticate it.

Fondly,
paultag


-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gdm3 depends on:
ii accountsservice 23.13.9-4
ii adduser 3.137
ii cool-retro-term [x-terminal-emulator] 1.2.0+ds2-1+b1
ii dbus [default-dbus-system-bus] 1.14.10-1
ii dbus-bin 1.14.10-1
ii dbus-daemon 1.14.10-1
ii dconf-cli 0.40.0-4
ii dconf-gsettings-backend 0.40.0-4
ii debconf [debconf-2.0] 1.5.82
ii foot [x-terminal-emulator] 1.15.3-1
ii gir1.2-gdm-1.0 45~beta-1
ii gnome-session [x-session-manager] 44.0-4
ii gnome-session-bin 44.0-4
ii gnome-session-common 44.0-4
ii gnome-settings-daemon 45~rc-1
ii gnome-shell 44.4-1
ii gnome-terminal [x-terminal-emulator] 3.49.99-1
ii gsettings-desktop-schemas 45~rc-1
ii libaccountsservice0 23.13.9-4
ii libaudit1 1:3.1.1-1
ii libc6 2.37-8
ii libcanberra-gtk3-0 0.30-10
ii libcanberra0 0.30-10
ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
ii libgdm1 45~beta-1
ii libglib2.0-0 2.78.0-1
ii libglib2.0-bin 2.78.0-1
ii libgtk-3-0 3.24.38-5
ii libgudev-1.0-0 238-2
ii libkeyutils1 1.6.3-2
ii libpam-modules 1.5.2-7
ii libpam-runtime 1.5.2-7
ii libpam-systemd [logind] 254.1-3
ii libpam0g 1.5.2-7
ii librsvg2-common 2.54.7+dfsg-2
ii libselinux1 3.5-1
ii libsystemd0 254.1-3
ii libx11-6 2:1.8.6-1
ii libxau6 1:1.0.9-1
ii libxcb1 1.15-1
ii libxdmcp6 1:1.1.2-3
ii polkitd 123-1
ii procps 2:4.0.3-1
ii systemd-sysv 254.1-3
ii ucf 3.0043+nmu1
ii x11-common 1:7.7+23
ii x11-xserver-utils 7.7+9+b1
ii xfce4-session [x-session-manager] 4.18.3-1
ii xfwm4 [x-window-manager] 4.18.0-1
ii xterm [x-terminal-emulator] 384-1

Versions of packages gdm3 recommends:
ii at-spi2-core 2.49.91-2
ii desktop-base 12.0.6+nmu1
ii gnome-session [x-session-manager] 44.0-4
ii x11-xkb-utils 7.7+7
ii xfce4-session [x-session-manager] 4.18.3-1
ii xserver-xephyr 2:21.1.8-1
ii xserver-xorg 1:7.7+23
ii zenity 3.44.2-1

Versions of packages gdm3 suggests:
pn libpam-fprintd <none>
ii libpam-gnome-keyring 42.1-1+b2
pn libpam-pkcs11 <none>
pn libpam-sss <none>
ii orca 44.1-2

-- debconf information excluded

[Simon McVittie]

Post by Paul Tagliamonte
I have NSS set up to talk with OpenSC

"NSS" is unfortunately ambiguous in this context. Is this the glibc Name
Service Switch (the thing that for example libnss-systemd integrates
with), or Mozilla's Netscape Security Services (libnss3), or some secret
third thing also named NSS?

Whichever one it is, can you be more specific about what was involved in
"setting it up to talk with OpenSC"?

smcv

[Paul Tagliamonte]

Post by Simon McVittie

Post by Paul Tagliamonte
I have NSS set up to talk with OpenSC

"NSS" is unfortunately ambiguous in this context. Is this the glibc Name
Service Switch (the thing that for example libnss-systemd integrates
with), or Mozilla's Netscape Security Services (libnss3), or some secret
third thing also named NSS?

Ah, very sorry. libnss3.

I usually use OpenSC in the following configuration:

```
modutil -add "OpenSC" \
-libfile /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so \
-dbdir sql:$HOME/.pki/nssdb
```

However, when I went to confirm my notes[1] against my running system, I
found it to be in a different state (using onepin-opensc-pkcs11.so,
which is new to me):

| An aside:
|
| [1]: My notes are in the form of manpages for stuf I do infrequently but
| want to remember. Here's a markdon of the yubkey manpage when I noodle
| with using it in OpenSC mode, in case this is helpful for more
| information: https://gist.github.com/paultag/2c35b62e85a032856c2cb97345c3d24d
|
| That's from 2017, so the world has changed quite a bit, and some of it
| is bad / outdated advice, so I'd just use it to help understand likely
| system configuration than best practice -- for instance, don't use
| pkcs#11 for ssh keys anymore pls :)

Related output when using `modutil -list -dbdir sql:$HOME/.pki/nssdb`

I'm seeing a slightly different configuration (hurmm, odd):

```
2. OpenSC smartcard framework (0.22)
library name: /usr/lib/x86_64-linux-gnu/onepin-opensc-pkcs11.so
uri: pkcs11:library-manufacturer=OpenSC%20Project;library-description=OpenSC%20smartcard%20framework;library-version=0.23
slots: 1 slot attached
status: loaded

slot:
token:
uri: pkcs11:
```

dpkg output from the packages I know about off the top of my head that
would be involved that aren't in the last report:

ii opensc 0.23.0-1 amd64 Smart card utilities with support for PKCS#15 compatible cards
ii opensc-pkcs11:amd64 0.23.0-1 amd64 Smart card utilities (PKCS#11 module)
ii libnss3:amd64 2:3.92-1 amd64 Network Security Service libraries
ii libnss3-dev:amd64 2:3.92-1 amd64 Development files for the Network Security Service libraries
ii libnss3-tools 2:3.92-1 amd64 Network Security Service tools
ii libykpiv-dev:amd64 2.2.0-1.1 amd64 Development files for the YubiKey PIV Library
ii libykpiv2:amd64 2.2.0-1.1 amd64 Library for communication with the YubiKey PIV smartcard
ii pcscd 2.0.0-1 amd64 Middleware to access a smart card using PC/SC (daemon side)
ii libccid 1.5.2-1 amd64 PC/SC driver for USB CCID smart card readers

[Raphael Hertzog]

Hello,

Post by Paul Tagliamonte
I upgraded my sid system, and post-upgrade gdm3 isn't showing my face
when I reboot, and entering my username causes it to loop back to
username entry again (no password prompt). After some help from smcv, I
narrowed down the issue to the interactions between my smartcard
development tools installed locally and gdm3.

In my case, I don't have any "smartcard development tools" (at least not
on purpose), I just have a smartcard inserted with a single GPG key used
for "authentication" (i.e. mainly for SSH logins).

$ gpg --card-status
Reader ...........: Alcor Micro AU9540 00 00
Application ID ...: D2760001240102010005000040DD0000
Application type .: OpenPGP
Version ..........: 2.1
Manufacturer .....: ZeitControl
[...]
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 32 32 32
PIN retry counter : 3 0 3
Signature counter : 0
Signature key ....: [none]
Encryption key....: [none]
Authentication key: 1CAC 8718 CAA0 C7B9 1EC0 E907 F1CA EE10 6CE6 97F8
created ....: 2022-01-19 08:31:51

Post by Paul Tagliamonte
(I do not have libpam-sss installed - after I got this error I installed
it to see if I could unlock myself, but it didn't do much and I purged
it again).

At least after I installed libpam-sss, I got an error message asking me
to introduce another smartcard so we could indeed figure out that it was
related to the smartcard.

Post by Paul Tagliamonte
My hunch is that I believe gdm-smartcard thinks it's supposed to kick
into gear and authenticate my smartcard, but it isn't configured to do
so (heck, it hasn't been told how to match my UPN/Email
SAN/Subject/Serial to UID, nor an x.509 CA to use for user
authentication). However, it kicking into gear has kicked me out of my
ability to login :)

That's likely due to the fact that gdm-smartcard required dependencies
(at least libpam-sss) were missing. So yeah it seems like that
gdm-smartcard should have a better failure mode when its prerequisites are
missing.

Putting here the reportbug generated info for the computer where I
experienced the issue:

Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable-security'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.4.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gdm3 depends on:
ii accountsservice 23.13.9-4
ii adduser 3.137
ii dbus [default-dbus-system-bus] 1.14.10-1
ii dbus-bin 1.14.10-1
ii dbus-daemon 1.14.10-1
ii dconf-cli 0.40.0-4
ii dconf-gsettings-backend 0.40.0-4
ii debconf [debconf-2.0] 1.5.82
ii gir1.2-gdm-1.0 45~beta-1
ii gnome-session [x-session-manager] 44.0-4
ii gnome-session-bin 44.0-4
ii gnome-session-common 44.0-4
ii gnome-settings-daemon 45~rc-1
ii gnome-shell 44.4-1
ii gnome-terminal [x-terminal-emulator] 3.49.99-1
ii gsettings-desktop-schemas 45~rc-1
ii libaccountsservice0 23.13.9-4
ii libaudit1 1:3.1.1-1
ii libc6 2.37-7
ii libcanberra-gtk3-0 0.30-10
ii libcanberra0 0.30-10
ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
ii libgdm1 45~beta-1
ii libglib2.0-0 2.78.0-1
ii libglib2.0-bin 2.78.0-1
ii libgtk-3-0 3.24.38-5
ii libgudev-1.0-0 237-2
ii libkeyutils1 1.6.3-2
ii libpam-modules 1.5.2-7
ii libpam-runtime 1.5.2-7
ii libpam-systemd [logind] 254.1-3
ii libpam0g 1.5.2-7
ii librsvg2-common 2.54.7+dfsg-2
ii libselinux1 3.5-1
ii libsystemd0 254.1-3
ii libx11-6 2:1.8.6-1
ii libxau6 1:1.0.9-1
ii libxcb1 1.15-1
ii libxdmcp6 1:1.1.2-3
ii metacity [x-window-manager] 1:3.49.1-1
ii mutter [x-window-manager] 44.4-2
ii polkitd 123-1
ii procps 2:4.0.3-1
ii systemd-sysv 254.1-3
ii ucf 3.0043+nmu1
ii x11-common 1:7.7+23
ii x11-xserver-utils 7.7+9+b1
ii xterm [x-terminal-emulator] 384-1

Versions of packages gdm3 recommends:
ii at-spi2-core 2.49.91-2
ii desktop-base 12.0.6+nmu1
ii gnome-session [x-session-manager] 44.0-4
ii x11-xkb-utils 7.7+7
ii xserver-xephyr 2:21.1.8-1
ii xserver-xorg 1:7.7+23
ii zenity 3.44.2-1

Versions of packages gdm3 suggests:
pn libpam-fprintd <none>
ii libpam-gnome-keyring 42.1-1+b2
pn libpam-pkcs11 <none>
pn libpam-sss <none>
ii orca 44.1-2

Cheers,

[Paul Tagliamonte]

Post by Raphael Hertzog
In my case, I don't have any "smartcard development tools" (at least not
on purpose), I just have a smartcard inserted with a single GPG key used
for "authentication" (i.e. mainly for SSH logins).

Ahha! As do I! I removed all my tokens, and understood smartcard to mean
an x.509 credential. My Debian signing key is on Hardware as well.

Post by Raphael Hertzog
$ gpg --card-status
Reader ...........: Alcor Micro AU9540 00 00
Application ID ...: D2760001240102010005000040DD0000
Application type .: OpenPGP
Version ..........: 2.1
Manufacturer .....: ZeitControl
[...]
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 32 32 32
PIN retry counter : 3 0 3
Signature counter : 0
Signature key ....: [none]
Encryption key....: [none]
Authentication key: 1CAC 8718 CAA0 C7B9 1EC0 E907 F1CA EE10 6CE6 97F8
created ....: 2022-01-19 08:31:51

Reader ...........: Yubico YubiKey FIDO CCID 00 00
Application ID ...: D2760001240102010006075352630000
Application type .: OpenPGP
Version ..........: 2.1
Manufacturer .....: Yubico
[...]
Name of cardholder: [not set]
Language prefs ...: [not set]
Salutation .......:
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: forced
Key attributes ...: rsa4096 rsa4096 rsa2048
Max. PIN lengths .: 127 127 127
PIN retry counter : [...]
Signature counter : [...]
Signature key ....: B7EC F42D DFD9 8AC7 301C 062B 1101 AD5A 8136 9AD7
created ....: 2019-02-09 15:52:11

paultag

[Harlan Lieberman-Berg]

Post by Paul Tagliamonte
I upgraded my sid system, and post-upgrade gdm3 isn't showing my face
when I reboot, and entering my username causes it to loop back to
username entry again (no password prompt).

Hello all,

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. That's still enough to trigger the bug,
however, even though there is no certificate for it to even attempt to
auth against.

For example:

```
❯ pkcs11-tool -L
Available slots:
Slot 0 (0x0): Yubico YubiKey OTP+FIDO+CCID 00 00
token label : PIV_II
token manufacturer : piv_II
token model : PKCS#15 emulated
token flags : login required, rng, token initialized, PIN
initialized, user PIN locked
hardware version : 0.0
firmware version : 0.0
serial num : 00000000
pin min/max : 4/8
```

However...

```
❯ pkcs11-tool --list-objects --type cert
Using slot 0 with a present token (0x0)
```

Sincerely,

[Simon McVittie]

Post by Harlan Lieberman-Berg
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

[Harlan Lieberman-Berg]

Post by Simon McVittie
If you run as root
update-alternatives --set gdm-smartcard /etc/pam.d/gdm-smartcard-sssd-or-password
does that restore previous functionality?

Sort of! It doesn't fix the changes to the UI (i.e., there is no
longer a list of users to select from; it is a username box where the
"go back" button does nothing), but you can login by putting the
username in by hand. That part is, obviously, the most important one.

Is the issue here one of defaults (e.g., the wrong PAM profile being
set), or one of detection (are smartcards a valid choice at all)?

Potentially unrelated sidenote: setting
`/org/gnome/login-screen/enable-smartcard-authentication` to `false`
has no effect on the ability to login; it still refuses to allow
password auth.

Sincerely,

[C]

I found myself here with the same issue (although it took a while to find
this bug): I have a YubiKey and suddenly at login my user would appear for
a split second and then be replaced by the blank username field.

After entering the username gdm3 would show "SSSD PAM module is not
installed. Smart card authentication is not supported, falling back to
default mechanism"
This started for me a few weeks ago, right around the time I installed
opensc for some smart card work I needed to do.

I managed to "fix" the behaviour (it's more of a workaround IMO) by running
this command

sudo -u Debian-gdm env -u XDG_RUNTIME_DIR -u DISPLAY DCONF_PROFILE=gdm
dbus-run-session gsettings set org.gnome.login-screen
enable-smartcard-authentication false

that Marco suggested on
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1933027/comments/17
(all I had to do was change the sudo username from gdm to Debian-gdm).
Neither the dconf workaround suggested above, nor setting the gsettings
entry on my user or as root, worked and I suspect it's because the value on
the Debian-gdm user takes precedence.

For the record I didn't try the other suggestion in the bug (creating
/etc/pam.d/gdm-password and using update-alternatives to set that as the
default for gdm-smartcard), but maybe Debian should have this as an option
for people that run into this issue?
If that's a valid option then believe it would be a simple addition to have
that file (even called something else, like "gdm-no-smartcard",
"gdm-password-only", etc.) in place, even if it's not the default.

Also of note, my installed alternative was "gdm-smartcard-sssd-exclusive"
and it was still falling back to password.

Hope this helps!

[Simon McVittie]

Neither [...], nor setting the gsettings entry
on my user or as root, worked and I suspect it's because the value on the
Debian-gdm user takes precedence.

Setting a gsettings entry for your user or for root is not expected to
affect the behaviour of the gdm greeter, because the gdm greeter does not
run as your user, or as root: it runs as Debian-gdm (or as gdm on Ubuntu).
So that part is as working as designed: if you want to change the behaviour
of the greeter, it is the Debian-gdm user's settings that must be changed,
and no other user's personal settings are going to affect it.

Neither the dconf workaround suggested above, nor [...], worked

What dconf workaround would that be? I don't see one in the previous
messages to this bug.

The intended way to change the settings of the Debian-gdm user is to edit
/etc/gdm3/greeter.dconf-defaults. In this case I think the equivalent would
be to locate the line "[org/gnome/login-screen]" and fill in
"enable-smartcard-authentication=false" below it, so it looks
something like this:

...
[org/gnome/login-screen]
enable-smartcard-authentication=false
logo='/usr/share/images/vendor-logos/logo-text-version-64.png'
...

And then restart gdm (the easiest/most reliable way is to reboot).

However, if you have already used a workaround that edits the user's

sudo -u Debian-gdm env -u XDG_RUNTIME_DIR -u DISPLAY DCONF_PROFILE=gdm
dbus-run-session gsettings set org.gnome.login-screen
enable-smartcard-authentication false

then that is probably going to take a higher priority than whatever you
write into /etc/gdm3/greeter.dconf-defaults.

For the record I didn't try the other suggestion in the bug (creating /etc/
pam.d/gdm-password and using update-alternatives to set that as the default for
gdm-smartcard), but maybe Debian should have this as an option for people that
run into this issue?
If that's a valid option then believe it would be a simple addition to have
that file (even called something else, like "gdm-no-smartcard",
"gdm-password-only", etc.) in place, even if it's not the default.

Marco designed the smart card handling setup that is currently used in
Debian, so I'm not going to make changes to it without understanding his
design intentions.

I personally think using smart cards as orthogonal to PAM authentication
is likely to be more common than using them for PAM authentication, and
if I understand correctly, using smart cards for authentication needs
sysadmin configuration *anyway* to associate each smartcard with a user
ID; so I would personally prefer it if the default was to use ordinary
password authentication, with some sort of opt-in for using smart cards
to authenticate, which sysadmins would be expected to enable after they
have enrolled users (set up the smartcard -> user mapping).

In RHEL, it seems to be opt-in:
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/using_the_desktop_environment_in_rhel_8/authenticating-the-user-in-the-desktop-environment_using-the-desktop-environment-in-rhel-8#configuring-smartcard-authentication-in-gdm-using-the-command-line_authenticating-the-user-in-the-desktop-environment
Doing the equivalent in Debian/Ubuntu might make more sense than trying
to guess whether smart card authentication is wanted from whether smart
card hardware happens to be plugged in?

Or, perhaps smart card authentication could be active if and only if
at least one smartcard -> user mapping has been created?

Or, perhaps enable-smartcard-authentication should be one of the fields
that is included in our example /etc/gdm3/greeter.dconf-defaults ready
for users to edit? The default could be either true or false, whichever
seems more appropriate.

smcv

[C]

Post by Simon McVittie
What dconf workaround would that be? I don't see one in the previous

messages to this bug.

Very sorry, I got confused: I read somewhere that creating a file in
/etc/dconf/[subdirectory I can't remember] would've solved this.
I can't find the place I read that anymore, and for some reason I believed
it was in this bug; however, I think it was exactly what the RedHat guide
you linked describes.

Post by Simon McVittie
The intended way to change the settings of the Debian-gdm user is to

edit /etc/gdm3/greeter.dconf-defaults [...]

Understood, thank you; I'll keep this in mind.

Post by Simon McVittie
I personally think using smart cards as orthogonal to PAM authentication
is likely to be more common than using them for PAM authentication [...]

Agreed; I also think there's more users tinkering with smart cards (or
installing smart card tooling as a dependency to some other software) than
there are users using them for authentication.

I don't know exactly what triggered this behaviour in GDM; I tried to
reproduce on a VM by installing opensc (which pulled in pcscd too) and
upgrading first to trixie and then sid, but nothing triggered it. It may be
another package, happy to test if you have suggestions.

Post by Simon McVittie
Or, perhaps enable-smartcard-authentication should be one of the fields
that is included in our example /etc/gdm3/greeter.dconf-defaults ready
for users to edit? The default could be either true or false, whichever
seems more appropriate.

IMO this seems appropriate, and matches your intention of not touching
Marco's design; I would default to false and document this as a requirement
for using smart card authentication, but it may be considered a breaking
change (the current default is true, I believe) so I'm not sure how you
want to handle it.

Post by Simon McVittie

Neither [...], nor setting the gsettings entry
on my user or as root, worked and I suspect it's because the value on the
Debian-gdm user takes precedence.

Setting a gsettings entry for your user or for root is not expected to
affect the behaviour of the gdm greeter, because the gdm greeter does not
run as your user, or as root: it runs as Debian-gdm (or as gdm on Ubuntu).
So that part is as working as designed: if you want to change the behaviour
of the greeter, it is the Debian-gdm user's settings that must be changed,
and no other user's personal settings are going to affect it.

Neither the dconf workaround suggested above, nor [...], worked

What dconf workaround would that be? I don't see one in the previous
messages to this bug.
The intended way to change the settings of the Debian-gdm user is to edit
/etc/gdm3/greeter.dconf-defaults. In this case I think the equivalent would
be to locate the line "[org/gnome/login-screen]" and fill in
"enable-smartcard-authentication=false" below it, so it looks
...
[org/gnome/login-screen]
enable-smartcard-authentication=false
logo='/usr/share/images/vendor-logos/logo-text-version-64.png'
...
And then restart gdm (the easiest/most reliable way is to reboot).
However, if you have already used a workaround that edits the user's

sudo -u Debian-gdm env -u XDG_RUNTIME_DIR -u DISPLAY DCONF_PROFILE=gdm
dbus-run-session gsettings set org.gnome.login-screen
enable-smartcard-authentication false

then that is probably going to take a higher priority than whatever you
write into /etc/gdm3/greeter.dconf-defaults.

For the record I didn't try the other suggestion in the bug (creating

/etc/

pam.d/gdm-password and using update-alternatives to set that as the

default for

gdm-smartcard), but maybe Debian should have this as an option for

people that

run into this issue?
If that's a valid option then believe it would be a simple addition to

have

that file (even called something else, like "gdm-no-smartcard",
"gdm-password-only", etc.) in place, even if it's not the default.

Marco designed the smart card handling setup that is currently used in
Debian, so I'm not going to make changes to it without understanding his
design intentions.
I personally think using smart cards as orthogonal to PAM authentication
is likely to be more common than using them for PAM authentication, and
if I understand correctly, using smart cards for authentication needs
sysadmin configuration *anyway* to associate each smartcard with a user
ID; so I would personally prefer it if the default was to use ordinary
password authentication, with some sort of opt-in for using smart cards
to authenticate, which sysadmins would be expected to enable after they
have enrolled users (set up the smartcard -> user mapping).
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/using_the_desktop_environment_in_rhel_8/authenticating-the-user-in-the-desktop-environment_using-the-desktop-environment-in-rhel-8#configuring-smartcard-authentication-in-gdm-using-the-command-line_authenticating-the-user-in-the-desktop-environment
Doing the equivalent in Debian/Ubuntu might make more sense than trying
to guess whether smart card authentication is wanted from whether smart
card hardware happens to be plugged in?
Or, perhaps smart card authentication could be active if and only if
at least one smartcard -> user mapping has been created?
Or, perhaps enable-smartcard-authentication should be one of the fields
that is included in our example /etc/gdm3/greeter.dconf-defaults ready
for users to edit? The default could be either true or false, whichever
seems more appropriate.
smcv

[Simon McVittie]

Post by Simon McVittie
What dconf workaround would that be? I don't see one in the previous
messages to this bug.

Very sorry, I got confused: I read somewhere that creating a file in /etc/dconf
/[subdirectory I can't remember] would've solved this.
I can't find the place I read that anymore, and for some reason I believed it
was in this bug; however, I think it was exactly what the RedHat guide you
linked describes.

Red Hat's setup for how gdm is configured is not quite the same as
Debian's, so Red Hat guides don't necessarily apply 100% to Debian.

smcv