gdm-smartcard pam config needs to be updated for Ubuntu and installed

Thanks, confirmed, unsure why Debian does that instead of using the upstream ones, it would be useful to report to Debian

reported to debian BTS, added link

comment from one of the Debian pkg-gnome maintainer

'the upstream gdm pam rules are not working out of the box due to nss not installing the NSSDB in /etc/pki/nssdb/ (which I think is a Fedoraism)'

Dimitri, why is a bug task opened on pam? The description doesn't point to this being a pam bug.

It has been brought to my attention by a UA customer that they are suffering from which seems a similar situation:

"
Our only currently working SmartCard access from Linux, over SSSD, to AD, is on RHEL7.
I was able to get SSH access on Ubuntu 20.04LTS, after adding "ad_gpo_access_control = permissive" in sssd.conf.

Logging in locally fails (prompting for password, rather than PIN). It is also still prompting for the Password twice on all local login attempts.

RHEL7 -> Ubuntu 20.04LTS (SSH) - Success
Ubuntu 20.04LTS -> RHEL7 (SSH) - Success
Ubuntu Desktop login (GDM or CLI) - Fail
Ubuntu Desktop login via local username/pw - Success, but with 2 pw prompts.
"

# git clone https://gitlab.gnome.org/GNOME/gdm.git

# find . -name "gdm-smartcard*"
./data/pam-arch/gdm-smartcard.pam
./data/pam-redhat/gdm-smartcard.pam
./data/pam-exherbo/gdm-smartcard.pam
./data/pam-lfs/gdm-smartcard.pam

It seems like Ubuntu/Debian will have to start by having a 'compatible' PAM stack config.

So far looking upstream, it seems to only be defined for 4 specific distros:
- Archlinux
- Redhat
- Exherbo
- Linux From Scratch (LFS)

Right, as pointed out in previous comments the configuration as it is today isn't workin on Debian/Ubuntu systems, the first step would be to have someone understand those pam details working out those parts

I unfortunately don't have a smartcard device handy to test/debug/.... but if I compare with RHEL which is known to be working...

Redhat has the following configuration "gdm-smarcard" which includes "smartcard-auth", a symlink pointing to "smartcard-auth-local"

I think we should 'mimic' this (at least as a starting point) without the selinux and other RHEL specific bits.

- Eric

g-s-d p11-kit backend ready at https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/merge_requests/208

The solution is going to require sssd which started being used in focal, we are not going to do official updates to bionic

While Bionic could be maybe supported, that would likely require newer SSSD.

Maybe in such case a pam_pkcs11 based solution could be provided, but it's quite a lot of backporting work which would need SRU team to agree with.

Lukasz (sil2100) can we have your SRU team input on this bug with regard to Bionic/18.04lTS ?

(I have ping sil2100 internally for him to provide his 2 cents on this bug.)

Though I do understand it is a bit annoying that smartcard login on bionic doesn't work, it worries me that fixing this would involve a lot of backporting. This isn't a regression and bionic has been like this from day 0, right? Do we have an understanding on how wanted this is on bionic?

I'm not saying no, but right now I wouldn't be comfortable in such a big set of changes without a rationale. I would rather recommend them to switch to focal and fixing it there. But I'd have to know more.

This bug was fixed in the package gnome-settings-daemon - 3.38.1-3ubuntu3

---------------
gnome-settings-daemon (3.38.1-3ubuntu3) hirsute; urgency=medium

  * debian/patches: Support smartcard reders via p11kit API (LP: #1865226)
  * debian/control: Build depend on libgck-1-dev and remove nss dependency
    (LP: #1865226)

 -- Marco Trevisan (Treviño) <email address hidden> Thu, 25 Feb 2021 04:53:56 +0100

This bug was fixed in the package gdm3 - 3.38.2.1-2ubuntu1

---------------
gdm3 (3.38.2.1-2ubuntu1) hirsute; urgency=medium

  * Merge with debian, containing new upstream version
  * debian/control: Don't Recommend pam fprintd module, as we seed it
  * debian/patches: Refresh
  * debian/gdm3.prerm: Resync with debian
  * debian/gdm3.gdm-smartcard-*: Add user_readenv=1 in pam_env.so
  * Remaining changes with debian:
    + readme.debian: update for correct paths in ubuntu
    + control.in:
      - don't recommend desktop-base
      - build depend on libgudev-1.0-dev
      - depend on bash for config_error_dialog.patch
      - update vcs field
    + rules:
      - don't override default user/group
      - -dgdm-xsession=true to install upstream xsession script
      - override dh_installinit with --no-start to avoid session being killed
    + rules, readme.debian, gdm3.8.pod:
      use upstream custom.conf instead of daemon.conf
    + gdm3.{postinst,postrm}: rename user and group back to gdm
    + gdm3.*.pam: make pam_env read ~/.pam_environment, as we use in g-c-c
      settings
    + gdm3.install:
      - stop installing default.desktop. it adds unnecessary clutter
        ("system default") to the session chooser.
      - don't install debian/xsession
    + add run_xsession.d.patch
    + add xresources_is_a_dir.patch
      - fix loading from /etc/x11/xresources/*
    + add nvidia_prime.patch:
      - add hook to run prime-offload (as root) and prime-switch if
        nvidia-prime is installed
    + add revert_override_lang_with_accountservices.patch:
      - on ubuntu accountservices only stores the language and not the
        full locale as needed by lang.
    + add dont_set_language_env.patch:
      - don't run the set_up_session_language() function, since it
        overrides variable values set by ~/.pam_environment
    + add config_error_dialog.patch:
      - show warning dialog in case of error in ~/.profile etc. and
        don't let a syntax error make the login fail
    + add debian/patches/revert_nvidia_wayland_blacklist.patch:
      - don't blacklist nvidia for wayland
    + add gdm3.service-wait-for-drm-device-before-trying-to-start-i.patch:
      - wait for the first valid gdm device on pre-start
    + add debian/default.pa
      - disable bluetooth audio devices in pulseaudio from gdm3.
    + debian/gdm3.install
      - added details of the default.pa file
    + debian/gdm3.postinst
      - added installation of default.pa and creation of dir if it doesn't
        exist.
    + debian/greeter.dconf-defaults: don't set debian settings in the
      greeter's dconf db

gdm3 (3.38.2.1-2) experimental; urgency=medium

  * debian: Add gdm-smartcard PAM module implemented with libpam_sss.
    The implementation uses update-alternatives to provide a generic
    gdm-smartcard PAM module that can be changed using the tool.
    Potentially other systems could be used or supported (such as pam_pkcs11
    or pam_p11) by adding other modules implementing the gdm-smartcard auth
    service. (LP: #1865226, Closes: #953557)
  * debian: Add gdm-smartcard implementation using pkcs11
  * debian/gdm3.gdm-smartcard-sssd-exclusive.pam:
    - PAM co...

Any idea when Focal will be completed ?

Regards,
Eric

There is an sssd package in focal-unapproved that points at this bug, with this d/changelog snippet:

  * debian/patches: Backport patches atches to support properly GDM smartcard
    login (LP: #1865226)
(sic)

But there is no sssd task in this bug.

I also don't see a gdm3 upload to focal unapproved, nor gnome-settings-daemon.

Can somebody please clarify this situation? What is needed in focal to fix this bug?

Also, this but is missing the SRU template, in case the sssd upload I mentioned in my previous comment is really addressing this bug.

Andreas:

 - I've now added SSSD to the bug
 - I had not uploaded the remaining bits yet as I was waiting for SSSD to hit the queue first
 - GNOME settings daemon is also uploaded now to the queue
 - GDM will be uploaded soon by Jeremy

The bug has now been updated to have a proper SRU template, with all the tests required to check all the 3 packages.

> Smartcard authentication using custom methods using via a custom configured system nss database may not work anymore.

Do I read the gnome-settings-daemon patches correctly, and this actually just entirely drops support for auth via NSS? So the regression potential is that if someone has set up auth via a custom system nss database, this *will* break login for them?

(Unrelatedly, patches like smartcard-Use-autopointers.patch and smartcard-manager-Use-mutex-auto-lockers-when-convenient.patch are the sort of refactoring patches that we prefer not to see in SRUs. I don't think they're a blocker, but they make reviewing more difficult)

gdm3 looks good to me, but I haven't accepted it yet as it depends on the gnome-settings-daemon patches and I think it's best to resolve those questions before accepting gdm3 into -proposed.

What's the status here? Questions are still unanswered after four months.

Sorry, I missed the previous comments.

> Do I read the gnome-settings-daemon patches correctly, and this actually just entirely drops support for auth via NSS? So the regression potential is that if someone has set up auth via a custom system nss database, this *will* break login for them?

Well, yes that's a regression potential that may indeed be mentioned, it's also something that we never supported though, since that required some extra setup in various places (write a gdm pam configuration, create the NSS database and configure pam-pkcs11/pam_sss). But indeed it could potentially affect someone who went through all this.

However... The SSSD side of this (lp:1905790), if one had configured a NSS database in the canonical location, it will be migrated (using this tool https://github.com/3v1n0/nss-database-pem-exporter).

So, it's quite a remote possibility but worth to mention in a clearer way (it was somewhat written already).

> Unrelatedly, patches like smartcard-Use-autopointers.patch and smartcard-manager-Use-mutex-auto-lockers-when-convenient.patch are the sort of refactoring patches that we prefer not to see in SRUs. I don't think they're a blocker, but they make reviewing more difficult

Let me know if I should drop them, one reason why they were added is that they were part of the upstream changes too, and so it made easier to ensure that we're both in the same line if problems may happen, making easier to backport patches in future if needed.