Bug#1077676: pcscd: unprivileged users not authorized to access OpenPGP smart cards
Package: pcscd
Version: 2.2.3-1
Severity: normal
Today I've rebooted my unattended-upgrades-enabled sid laptop after a
long time (almost 70 days) and discovered I could not access my smart
cards anymore.
from syslog:
pcscd: ../src/auth.c:145:IsClientAuthorized() Process 31413 (user: 1000) is NOT
authorized for action: access_pcsc
pcscd: ../src/winscard_svc.c:355:ContextThread() Rejected unauthorized PC/SC
client
I had to add a polkit rule in order to allow my unprivileged self to use
the cards:
> sudo cat /etc/polkit-1/rules.d/40-allow-pcscd.rules
polkit.addRule(function(action, subject) {
if (
subject.isInGroup("plugdev")
&& (
action.id === "org.debian.pcsc-lite.access_pcsc"
|| action.id === "org.debian.pcsc-lite.access_card"
)
) {
return polkit.Result.YES;
}
return polkit.Result.NOT_HANDLED;
});
Given the long time since the previous reboot, I don't know when the
problem has started or where it has originated.
Maybe pcscd has started being linked against polkit only recently? If
this is the case, I suggest shipping with the package a polkit rule
similar to the one above and adding a NEWS entry to warn the users. This
would particularly benefit users that depend on the smart card for
logging in.
Thanks,
Gian Piero.
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.9.12-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled
Versions of packages pcscd depends on:
ii libc6 2.39-6
ii libccid [pcsc-ifd-handler] 1.6.1-1
ii libglib2.0-0t64 2.80.4-1
ii libpcsclite12.2.3-1
ii libpolkit-gobject-1-0 124-3
ii libsystemd0 256.4-2
ii libudev1256.4-2
pcscd recommends no packages.
Versions of packages pcscd suggests:
pn systemd
-- no debconf information
Bug#1077676: pcscd: unprivileged users not authorized to access OpenPGP smart cards
Hello Gian,
Le 31/07/2024 à 22:14, Gian Piero Carrubba a écrit :
Package: pcscd
Version: 2.2.3-1
Severity: normal
Today I've rebooted my unattended-upgrades-enabled sid laptop after a
long time (almost 70 days) and discovered I could not access my smart
cards anymore.
from syslog:
pcscd: ../src/auth.c:145:IsClientAuthorized() Process 31413 (user: 1000) is NOT
authorized for action: access_pcsc
pcscd: ../src/winscard_svc.c:355:ContextThread() Rejected unauthorized PC/SC
client
I had to add a polkit rule in order to allow my unprivileged self to use
the cards:
sudo cat /etc/polkit-1/rules.d/40-allow-pcscd.rules
polkit.addRule(function(action, subject) {
if (
subject.isInGroup("plugdev")
&& (
action.id === "org.debian.pcsc-lite.access_pcsc"
|| action.id === "org.debian.pcsc-lite.access_card"
)
) {
return polkit.Result.YES;
}
return polkit.Result.NOT_HANDLED;
});
Given the long time since the previous reboot, I don't know when the
problem has started or where it has originated.
polkit is enabled by default since pcsc-lite 2.0.1 from Nov 2023.
See https://blog.apdu.fr/posts/2023/11/new-version-of-pcsc-lite-201/
So I am surprised you have the issue only now.
Maybe pcscd has started being linked against polkit only recently? If
this is the case, I suggest shipping with the package a polkit rule
similar to the one above and adding a NEWS entry to warn the users. This
would particularly benefit users that depend on the smart card for
logging in.
Local users should have access to pcsc-lite by default
See https://blog.apdu.fr/posts/2023/11/pcsc-lite-and-polkit/
Your problem occurs on the login screen?
Or after you are logged in?
Bye
--
Dr. Ludovic Rousseau
Bug#1077676: pcscd: unprivileged users not authorized to access OpenPGP smart cards
reassign -1 elogind merge -1 1076728 thanks * [Wed, Jul 31, 2024 at 10:55:31PM GMT] Ludovic Rousseau: Local users should have access to pcsc-lite by default See https://blog.apdu.fr/posts/2023/11/pcsc-lite-and-polkit/ Thanks, I'd missed the default policy was in place. cat /usr/share/polkit-1/actions/org.debian.pcsc-lite.policy ... no no yes ... It seems the problem resides in elogind not identifying the current session as active. Reassigning. Thanks, Gian Piero.
Bug#1077676: pcscd: unprivileged users not authorized to access OpenPGP smart cards
dpkg -l \*elogin\* \*systemd\* | grep ^ii ii elogind 255.5-1debian2 amd64user, seat and session management daemon ii libpam-elogind:amd64255.5-1debian2 amd64elogind PAM module ii libsystemd0:amd64 256.4-2amd64systemd utility library ii systemd-standalone-sysusers 256.4-2amd64standalone sysusers binary for use in non-systemd systems cat /etc/pam.d/common-session # # /etc/pam.d/common-session - session-related modules common to all services # # This file is included from other service-specific PAM config files, # and should contain a list of modules that define tasks to be performed # at the start and end of interactive sessions. # # As of pam 1.0.1-6, this file is managed by pam-auth-update by default. # To take advantage of this, it is recommended that you configure any # local modules either before or after the default block, and use # pam-auth-update to manage selection of other modules. See # pam-auth-update(8) for details. # here are the per-package modules (the "Primary" block) session [default=1] pam_permit.so # here's the fallback if no module succeeds session requisite pam_deny.so # prime the stack with a positive return value if there isn't one already; # this avoids us returning an error just because nothing sets a success code # since the modules above will each just jump around session requiredpam_permit.so # reset the umask for new sessions session optionalpam_umask.so # and here are more per-package modules (the "Additional" block) session required pam_unix.so session optional pam_elogind.so # end of pam-auth-update config loginctl list No sessions.
Bug#1077676: pcscd: unprivileged users not authorized to access OpenPGP smart cards
The problem seems to be that update-rc.d orders the init scripts so that xdm starts before elogind, so waiting for elogind to start before logging in solves the issue. Is this something the elogind package can solve? My guess is that's xdm's (and other dm) duty... Thanks, Gian Piero.
Bug#1077676: pcscd: unprivileged users not authorized to access OpenPGP smart cards
Hi, On Thu, Aug 01, 2024 at 01:04:11AM +0200, Gian Piero Carrubba wrote: > The problem seems to be that update-rc.d orders the init scripts so that xdm > starts before elogind, so waiting for elogind to start before logging in > solves the issue. > > Is this something the elogind package can solve? My guess is that's xdm's > (and other dm) duty... I don't think there is a bug in elogind here, or anything elogind can do about it. AFAIK xdm doesn't use logind (systemd or elogind). So if you want to enforce this ordering xdm, try adding # X-Start-Before: elogind in /etc/init.d/xdm. Mark
Bug#1077676: pcscd: unprivileged users not authorized to access OpenPGP smart cards
* [Thu, Aug 01, 2024 at 07:33:46AM GMT] Mark Hindley: On Thu, Aug 01, 2024 at 01:04:11AM +0200, Gian Piero Carrubba wrote: The problem seems to be that update-rc.d orders the init scripts so that xdm starts before elogind, so waiting for elogind to start before logging in solves the issue. Is this something the elogind package can solve? My guess is that's xdm's (and other dm) duty... I don't think there is a bug in elogind here, or anything elogind can do about it. AFAIK xdm doesn't use logind (systemd or elogind). The problem is registering an xdm-initiated session with elogind. /etc/pam.d/xdm includes /etc/pam.d/common-session that calls libpam-elogind, so in this sense xdm uses elogind. So if you want to enforce this ordering xdm, try adding # X-Start-Before: elogind in /etc/init.d/xdm. It's the other way around: it's /etc/init.d/elogind that should include # X-Start-Before: xdm but obviously that would only work for xdm and not for other display managers. But I've just discovered that xdm ships /etc/insserv.conf.d/xdm that reads: $x-display-manager xdm So, if the $x-display-manager is standardized by the Debian Policy (i.e., all the display managers define the facility) and if it would not cause problems on systems that don't have a display manager installed (I haven't tested), the solution should be for elogind to include # X-Start-Before: $x-display-manager in its own init script. Thanks, Gian Piero.
Bug#1077676: pcscd: unprivileged users not authorized to access OpenPGP smart cards
On Thu, Aug 01, 2024 at 09:02:07AM +0200, Gian Piero Carrubba wrote: > So, if the $x-display-manager is standardized by the Debian Policy (i.e., > all the display managers define the facility) I think most do, but it is no longer policy. > and if it would not cause > problems on systems that don't have a display manager installed (I haven't > tested), the solution should be for elogind to include > > # X-Start-Before: $x-display-manager I am not averse to this, but I am not sure it addresses all cases. In particular non-graphical login to a console. I also wonder how you manage to login to xdm before elogind has had chance to start? Mark
Bug#1077676: pcscd: unprivileged users not authorized to access OpenPGP smart cards
* [Thu, Aug 01, 2024 at 09:45:38AM GMT] Mark Hindley: I also wonder how you manage to login to xdm before elogind has had chance to start? xdm does not depend on elogind for logging in, it just registers a new session with elogind via pam: grep elogin /etc/pam.d/common-session session optionalpam_elogind.so Given it's optional, I think it's normal (and wished for) that it doesn't croak when the connection to elogind fails. Ciao, Gian Piero.
Bug#1077676: pcscd: unprivileged users not authorized to access OpenPGP smart cards
Control: tags -1 patch Gian, On Thu, Aug 01, 2024 at 09:02:07AM +0200, Gian Piero Carrubba wrote: > It's the other way around: it's /etc/init.d/elogind that should include > > # X-Start-Before: xdm Attached is the patch I have queued. Could you apply it to /etc/init.d/elogind and verify that it fixes the behaviour for you? I have noticed and fixed the typo in the description separately. It appears the following display managers include a fragments in /etc/insserv.conf.d: - gdm3 /etc/insserv.conf.d/gdm3 - kdm /etc/insserv.conf.d/kdm - lxdm /etc/insserv.conf.d/lxdm /etc/insserv.conf.d/lxdm.insserv - nodm /etc/insserv.conf.d/nodm - wdm /etc/insserv.conf.d/wdm - xdm /etc/insserv.conf.d/xdm The conspicuous absences are sddm and lightdm. Mark >From 1706b83e641e21f41a0a2ec11bb7d82f25fccfda Mon Sep 17 00:00:00 2001 From: Mark Hindley Date: Sun, 4 Aug 2024 07:19:30 +0100 Subject: [PATCH] d/elogind.init: start before $x-display-manager. Closes: 1077676 --- debian/elogind.init | 1 + 1 file changed, 1 insertion(+) diff --git a/debian/elogind.init b/debian/elogind.init index 13a156f6a..2014cd06d 100644 --- a/debian/elogind.init +++ b/debian/elogind.init @@ -3,6 +3,7 @@ # Provides: elogind # Required-Start: dbus $remote_fs $syslog # Required-Stop: dbus $remote_fs $syslog +# X-Start-Before: $x-display-manager # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: start elogind at boot tim -- 2.39.2
Bug#1077676: pcscd: unprivileged users not authorized to access OpenPGP smart cards
* [Sun, Aug 04, 2024 at 07:44:47AM GMT] Mark Hindley: Attached is the patch I have queued. Could you apply it to /etc/init.d/elogind and verify that it fixes the behaviour for you? I cannot reboot the laptop now. Also, I already had the patch in place, so I've recreated the issue artificially: - removed the X-Start-Before line - modified the Required-Start so to have elogind start after $x-display-manager - confirmed with `sudo rc-status` that openrc would start elogind after xdm - run `sudo update-rc.d elogind defaults` and confirmed the links in /etc/rc?.d/ have been changed accordingly I've then restored the Required-Start line and readded the X-Start-Before line and confirmed, both with `rc-status` and `update-rc.d`, that elogind would start before xdm. This should be enough to validate the change. The only reason for it not to still work would be if elogind daemonized but didn't register the session (e.g.: it still is in an hypothetical initialization phase) when an user logs in, but that's not something openrc/sysvrc could prevent. Thanks, Gian Piero.
