Make polkit rules work again

Thanks to Mike Kazantsev for the bug report and nice analysis
"PrivateUsers=yes in systemd sandboxing options prevents polkit rules from getting user/group info #231"
Closes: #231

The analysis bellow is a copy/paste from Mike Kazantse issue.

Describe the bug

pcsc-lite stopped working for polkit-authorized process in 2.3.2
release, due to PrivateUsers=yes in systemd hardening options stripping
user/group info (mapping those to 65534 "nobody" user).

To Reproduce

It fails with the following symptoms:

 - Running "id" in the process 96851 that tries to access pcsc-lite shows:

    uid=976(pcsc-access) gid=976(pcsc-access) groups=976(pcsc-access),986(othergroup)

 - Adding polkit.log("subject=" + subject) to /etc/polkit-1/rules.d/11-pcsc.rules (and running polkitd with --log-level=debug) prints the following (to journalctl/syslog):

    polkitd[96664]: subject=[Subject pid=96851 user='nobody' groups=nobody seat=null session=null system_unit=null local=false active=false]

    This prevents pcsc-access gid-check from working in that
11-pcsc.rules file, as accessing process looks pretty much anonymous to
polkitd.

 - This is followed by this error from pcsc-lite (due to polkit access
check result):

    pcscd[96810]: 53709592 ../PCSC/src/auth.c:166:IsClientAuthorized() Process 96851 (user: 65534) is NOT authorized for action: access_pcsc

 Again, note user: 65534 - this is incorrect from a root userns
perspective (i.e. running ps as root).

Expected behavior

With usage scenario as described above, expected behavior is:

 - Running "id" in the process 96851 that tries to access pcsc-lite
   shows same thing - it has correct "pcsc-access" group.
 - "subject" in polkitd check initiated by pcsc-lite has that same
   pcsc-access group, so that process can be authorized via polkit
   rule matching that.
 - pcscd grants access after polkit rule is able to match correct
   subject and return YES verdict.

It works like that with pcsc-lite 2.3.1 release.

Additional context

I've looked at sandboxing options, and clear culprit there seem to be
using uid/gid namespacing via PrivateUsers=yes.  Afaik this should map
all uids/gids to special "nobody", as documented in systemd.exec(5):

    If set to a true value or "self", a minimal user and group mapping
    is configured that maps the "root" user and group as well as the
    unit's own user and group to themselves and everything else to the
    "nobody" user and group.

And this seem to be what happens, according to polkitd and pcscd output above.

Disabling this option makes polkit rule log following expected "subject" value:

subject=[Subject pid=98640 user='pcsc-access' groups=pcsc-access,othergroup seat=null session=null system_unit=null local=false active=false]

Setting PrivateUsers=identity value instead of yes/true also works to
the same (expected) result, so I think maybe that value should be used
there instead, to avoid breaking existing polkit rules, as well as
making it more difficult to identify processes there (with user/group
info stripped).

Author: LudovicRousseau

etc/pcscd.service.in

@@ -25,7 +25,7 @@ UMask=0077
 ProtectSystem=strict
 ProtectHome=yes
 PrivateTmp=yes
-PrivateUsers=yes
+PrivateUsers=identity
 ProtectHostname=yes
 ProtectClock=yes
 ProtectKernelTunables=yes