On Fri, 21 Jun 2024 at 12:55:34 +0200, C wrote: > 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 settings, like this one: > 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
