> 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. > 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. > 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. > 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. On Fri, Jun 21, 2024 at 3:55 PM Simon McVittie <s...@debian.org> wrote: > 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 >
