Bug#1051785: workaround

[Simon McVittie]

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