PCSC does not work when hidepid is used for /proc

[xoores]

On my system (Gentoo) I have a /proc mounted with hidepid=2 and it prevents PCSC from working as it tries to access info about a process that does not belong to my user. When the PID check fails, the PCSC reject sign request.

When I remount /proc with hidepid=0 (1 does not work also), everything works. This started happening (I believe) when I upgraded to 2.3.0, it did not happen before.

Kernel: 6.13.2-gentoo
PCSC: 2.3.0

PCSC is running under pcscd user and therefore it does not have access to /proc folders of my user (UID 1000) - as is intended for hidepid:

# ps aux | grep pcsc
pcscd     4204  0.0  0.0 239316  3464 ?        Sl   16:20   0:00 /usr/sbin/pcscd

/etc/fstab

...
proc   /proc   proc   nosuid,nodev,noexec,hidepid=2,gid=proc   0 0

/etc/polkit-1/rules.d/pcsc.rules

polkit.addRule(function(action, subject) {
	if (action.id == "org.debian.pcsc-lite.access_pcsc" ||
		action.id == "org.debian.pcsc-lite.access_card")
	{
		polkit.log("PCSC: action=" + action + "  subject=" + subject);
		return polkit.Result.YES;
	}
	
	polkit.log("PCSC-UNHANDLED: action=" + action + "  subject=" + subject);
});

Relevant logs:

17.02 13:16:38  pcscd[12454]: ../pcsc-lite-2.3.0/src/auth.c:127:IsClientAuthorized() Error in authorization: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code4: Failed to open file “/proc/12699/status”: No such file or directory
17.02 13:16:38  pcscd[12454]: ../pcsc-lite-2.3.0/src/auth.c:145:IsClientAuthorized() Process 12699 (user: 1000) is NOT authorized for action: access_pcsc
17.02 13:16:38  pcscd[12454]: ../pcsc-lite-2.3.0/src/winscard_svc.c:357:ContextThread() Rejected unauthorized PC/SC client
17.02 13:16:41  pcscd[12454]: ../pcsc-lite-2.3.0/src/auth.c:127:IsClientAuthorized() Error in authorization: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code4: Failed to open file “/proc/12699/status”: No such file or directory
17.02 13:16:41  pcscd[12454]: ../pcsc-lite-2.3.0/src/auth.c:145:IsClientAuthorized() Process 12699 (user: 1000) is NOT authorized for action: access_pcsc
17.02 13:16:41  pcscd[12454]: ../pcsc-lite-2.3.0/src/winscard_svc.c:357:ContextThread() Rejected unauthorized PC/SC client

[LudovicRousseau]

pcscd should run as root.
Why does it run under user pcscd? Do you use a custom installation?

In your example what is the process with pid=12699?

[xoores]

No, this is an official Gentoo package, no custom package. The pcscd runs as pcscd:pcscd - it was like this for many years. The package even says so when installing:

Starting from version 1.6.5, pcsc-lite will start as user nobody in the pcscd group, to avoid running as root.

This also means you need the newest drivers available so that the devices get the proper owner.

As I said, it worked well until recently - I can test previous version of pcsc to check if you need 🙂 Running as root would definitely fix the issue, but would it be better? I mean security-wise. Because it seems like there are 3 possible was out:

1. Drop the hidepid from my fstab - although doable, it is a hardening feature and it does limit reach of processes running under my user. For now I just do mount -o remount,hidepid=0 /proc as a "hotfix" 😅

2. Disable that /proc check - I don't know the implications of this and I don't know why this was introduced so I can't really say whether this is a good idea or not. I haven't really looked into the sources yet.

3. Run pcscd as root - Although definitely possible (and probably currently the official way), I would say that dropping root privileges is also quite a good and strong security feature and that it could maybe be considered to be adopted instead of running as root? It is much harder to exploit process that has no real privileges to begin with.

12699 is scdaemon, running under my user - and that's why pcscd cannot access any info about it through /proc:

xoores   12699  0.0  0.0  93160  3676 ?        SLl  13:16   0:02 scdaemon --multi-server

[xoores]

I've done some rudimentary source code digging and the problem probably does not come from pcsc as I thought originally.

I used to compile pcsc without polkit enabled - and disabling polkit just bypasses IsClientAuthorized(). So the problem may not even be related with me upgrading pcsc but to the Polkit itself - probably somewhere in the polkit_authority_check_authorization_sync() call (or related methods). I have not yet pinpoint the exact location of the problem, because Polkit uses DBUS and that is a huge pain to follow through (atleast for me), but I will try to keep on digging.

Strange 😳

edit: Touché 🤦 Sorry for wasting your time, this indeed is not a problem of PCSC... Thank you for you quick reply though!

Also more reading on RedHat Bugzilla discussing this very problem (albeit in different situation), closed as CANTFIX without any resolution from 2014. And it is not the only one bugreport, too.

Polkit seems to be just a mess without any chance of fixing in the near future 😅

[LudovicRousseau]

The error message Error in authorization: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code4: clearly indicates it comes from polkit (or dbus used y polkit).

You can rebuild pcsc-lite without polkit enabled, or use --disable-polkit as pcscd argument.
You can add this option in /etc/default/pcscd. See https://blog.apdu.fr/posts/2021/08/pcsc-lite-configuration-using/

[xoores]

Yeah, I know, right? Such an obvious message, I don't know how I could have missed it 😁

I can confirm that the --disable-polkit option does indeed work with hidepid=2.

Thanks again - not only for your help, but also for pcsc! Been using it for years without any problems. Great work! 😎

[LudovicRousseau]

Thanks for the sponsoring.

I will try to install a Gentoo system to see how pcsc-lite + libccid is configured.

[xoores]

My pleasure, I've been using pcsc for so long & this is a good way to thank you for your time & effort 🙂

If you need any help with Gentoo, LMK - it can be an overwhelming experience for the first time, but it definitely is worth it in my opinion.

[bluetech]

No, this is an official Gentoo package, no custom package. The pcscd runs as pcscd:pcscd - it was like this for many years. The package even says so when installing

Interesting. The upstream pcsclite has reverted the change you quoted when switching to systemd, and so pcscd upstream has been running as root for many years. So I was very curious when you said that Gentoo runs it with pcscd:pcscd. Turns out that since the end of 2022 Gentoo is applying a special patch to make pcscd run as a special user. See:

• Package files
• Commit, Fixup commit to add missing udev rules
• Bug

We are just working on making upstream pcscd run under a pcscd user so it's good to see that many users are already successfully running with such a configuration.

[xoores]

Yup, it has been running as pcscd for a long time 🙂 And it is working flawlessly - no issues at all as far as I can remember.

I'm using pcsc with several Yubikeys and apart from an annoying Yubikey USB behavior (not being able to sleep/idle therefore it drains laptop battery unnecessarily as USB controller cannot idle and also breaking "modern sleep" when Yubi is plugged in) I had no issues.

I honestly quite like the approach Gentoo is taking in this case. I consider the effort to limit the amount of services running under root as a very good thing.

[LudovicRousseau]

pcsc-lite version 2.3.2 uses a hardened systemd configuration
https://blog.apdu.fr/posts/2025/03/new-version-of-pcsc-lite-232/

I am also testing running pcscd as a normal user. The code is in the -devel repos https://github.com/LudovicRousseau/PCSC-devel & https://github.com/LudovicRousseau/CCID-devel and works fine for me so far.

I don't know exactly what to do with the hidepid problem. I think we have only two options:

1. do not use hidepid option for mount
2. do not use polkit for pcsc-lite

Any other idea?

[LudovicRousseau]

With pcsc-lite 2.4.0 the daemon process now runs as a normal user.
See https://blog.apdu.fr/posts/2025/10/pcscd-runs-as-pcscd-user/

I don't know the impacts regarding hidepid option for mount