[SOLVED] Polkit policy file not working, or is the provider wrong ?

tomsam · 2025-11-12 19:21:13

Hi,

my smart card reader had been working for years, until this October, when the author of the pcscd decided that the daemon from version 2.4.0 on has to run as user pcscd.
The author claims that

* the reader device must be set to group pcscd
* the driver of the reader must provide udev rules for that
* there is no solution without udev rules

Since the driver of my reader does not provide udev rules, pcscd crashes with a segv and no readers are visible in the system.
(The device is root root instead of root pcscd in that case, an open fails, and because the driver software is buggy at that place, it doesn't exit correctly)

However, the producer of my reader tells me that they refuse to provide udev rules, and instead will provide a polkit .policy file that would do all the things (and also set the device's group to pcscd), and it is supposed to work for all readers, not only the ones from them. On top they claim that this is working in Debian 13 (which is wrong, because Debian 13 does not have pcscd 2.4.0, but Debian sid/forky does, and there indeed the device seems to be set to group pcscd and all is working fine without udev rules (at least I haven't found any)).

Can anyone tell me

1. Does that policy file below really set the device group to pcscd ? -or- Should the file below give the users access to all readers in the system, even if the device group is not changed?
2. Does anyone have an idea, why the whole thing works in Debian sid/forky, and does not work in arch ?
3. Can it be that some identifiers in that file have to be renamed to work with arch ?

Regards,
tomsam

$ pacman -Q | grep polkit
polkit 126-2
polkit-gnome 0.105-11
polkit-qt6 0.200.0-1

The file is as below, and the actions are listed in pkaction --verbose correctly :

org.debian.pcsc-lite.access_card:
  description:       Access to the smart card
  message:           Authentication is required to access the smart card
  vendor:            The PCSC-lite Project
  vendor_url:        [url]https://pcsclite.apdu.fr/[/url]
  icon:              
  implicit any:      no
  implicit inactive: no
  implicit active:   yes
  annotation:        org.freedesktop.policykit.owner -> unix-user:pcscd

org.debian.pcsc-lite.access_pcsc:
  description:       Access to the PC/SC daemon
  message:           Authentication is required to access the PC/SC daemon
  vendor:            The PCSC-lite Project
  vendor_url:        [url]https://pcsclite.apdu.fr/[/url]
  icon:              
  implicit any:      no
  implicit inactive: no
  implicit active:   yes
  annotation:        org.freedesktop.policykit.owner -> unix-user:pcscd

org.debian.pcsc-lite.policy file (as already provided by pcsclite):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
 "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
 "[url]http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd[/url]">
<policyconfig>
  <vendor>The PCSC-lite Project</vendor>
  <vendor_url>https://pcsclite.apdu.fr/</vendor_url>
<!--  <icon_name>smart-card</icon_name> -->

  <action id="org.debian.pcsc-lite.access_pcsc">
    <description>Access to the PC/SC daemon</description>
    <message>Authentication is required to access the PC/SC daemon</message>
    <annotate key="org.freedesktop.policykit.owner">unix-user:pcscd</annotate>
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>

  <action id="org.debian.pcsc-lite.access_card">
    <description>Access to the smart card</description>
    <message>Authentication is required to access the smart card</message>
    <annotate key="org.freedesktop.policykit.owner">unix-user:pcscd</annotate>
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>

</policyconfig>

Last edited by tomsam (2025-11-28 06:57:01)

seth · 2025-11-12 21:21:11

Please use [code][/code] tags. Edit your post in this regard.

The polkit rule will allow any process run by pcscd to check that any user w/ an active session can invoke the polkit actions org.debian.pcsc-lite.access_pcsc and org.debian.pcsc-lite.access_card
This seems nothing new, see eg https://www.redhat.com/en/blog/controll … mart-cards from 2014

2. Does anyone have an idea, why the whole thing works in Debian sid/forky, and does not work in arch ?

loginctl session-status

If you're using xinit/startx, see the last link below and the 2nd blue note on what to include at least.

tomsam · 2025-11-12 21:49:58

If that was the request to do a "loginctl session-status", then it is as follows, where I replaced my user id by tomsam:

2 - tomsam (1000)
  Since: Wed 2025-11-12 22:41:26 CET; 4min 14s ago
  State: active
 Leader: 1261 (lightdm)
   Seat: seat0; vc7
Display: :0
 Remote: no
Service: lightdm
   Type: x11
  Class: user
Desktop: xfce
   Idle: no
   Unit: session-2.scope
         ├─ 1261 lightdm --session-child 13 20
         ├─ 1594 xfce4-session
         ├─ 1670 xfwm4
         ├─ 1689 xfsettingsd
         ├─ 1708 xfce4-panel
         ├─ 1714 Thunar --daemon
         ├─ 1723 xfdesktop
         ├─ 1728 /usr/lib/xfce4/panel/wrapper-2.0 /usr/lib/xfce4/panel/plugins/libwhiskermenu.so 7 12582919 whiskermenu "Whisker Menu" "Show a menu to easily access installed applications"
         ├─ 1733 /usr/lib/xfce4/panel/wrapper-2.0 /usr/lib/xfce4/panel/plugins/libweather.so 19 12582920 weather "Weather Update" "Show current weather conditions"
         ├─ 1734 /usr/lib/xfce4/panel/wrapper-2.0 /usr/lib/xfce4/panel/plugins/libsystray.so 6 12582921 systray "Status Tray Plugin" "Provides status notifier items (application indicators) and legacy systray items"
         ├─ 1735 /usr/lib/xfce4/panel/wrapper-2.0 /usr/lib/xfce4/panel/plugins/libpulseaudio-plugin.so 8 12582922 pulseaudio "PulseAudio Plugin" "Adjust the audio volume of the PulseAudio sound system"
         ├─ 1736 /usr/lib/xfce4/panel/wrapper-2.0 /usr/lib/xfce4/panel/plugins/libxfce4powermanager.so 9 12582923 power-manager-plugin "Power Manager Plugin" "Display the battery levels of your devices and control the brightness of your display"
         ├─ 1738 /usr/lib/xfce4/panel/wrapper-2.0 /usr/lib/xfce4/panel/plugins/libnotification-plugin.so 10 12582924 notification-plugin "Notification Plugin" "Notification plugin for the Xfce panel"
         ├─ 1759 /usr/lib/xfce4/panel/wrapper-2.0 /usr/lib/xfce4/panel/plugins/libactions.so 14 12582926 actions "Action Buttons" "Log out, lock or other system actions"
         ├─ 1834 /usr/local/bin/MolchEncfsManager.x86_64
         ├─ 1835 nm-applet
         ├─ 1840 xfce4-power-manager
         ├─ 1842 picom -b
         ├─ 1843 /usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1
         ├─ 1845 xfce4-screensaver
         ├─ 1846 /usr/lib/geoclue-2.0/demos/agent
         ├─ 1856 /usr/bin/fcitx5
         ├─ 8799 /usr/bin/xfce4-terminal
         ├─ 8821 ksh
         ├─ 8856 conky -p 10 -d
         ├─52887 bwrap --unshare-all --die-with-parent --chdir / --ro-bind /usr /usr --dev /dev --ro-bind-try /etc/ld.so.cache /etc/ld.so.cache --ro-bind-try /nix/store /nix/store --tmpfs /tmp-home --tmpfs /tmp-run --clearenv --setenv HOME /tmp-home --setenv XDG_RUNTIME_DIR /tmp-run --setenv XDG_RUNTIME_DIR /run/user/1000 --symlink /usr/lib /lib64 --symlink /usr/lib /lib --ro-bind-try /etc/fonts/conf.d /etc/fonts/conf.d --ro-bind-try /etc/fonts/fonts.conf /etc/fonts/fonts.conf --ro-bind-try /home/tomsam/.cache/fontconfig /home/tomsam/.cache/fontconfig --ro-bind-try /home/tomsam/.fonts /home/tomsam/.fonts --ro-bind-try /home/tomsam/.local/share/fonts /home/tomsam/.local/share/fonts --ro-bind-try /var/cache/fontconfig /var/cache/fontconfig --bind-try /home/tomsam/.cache/glycin/usr/lib/glycin-loaders/2+/glycin-svg /home/tomsam/.cache/glycin/usr/lib/glycin-loaders/2+/glycin-svg --setenv XDG_CACHE_HOME /home/tomsam/.cache/glycin/usr/lib/glycin-loaders/2+/glycin-svg --seccomp 24 /usr/lib/glycin-loaders/2+/glycin-svg --dbus-fd 22
         ├─52888 bwrap --unshare-all --die-with-parent --chdir / --ro-bind /usr /usr --dev /dev --ro-bind-try /etc/ld.so.cache /etc/ld.so.cache --ro-bind-try /nix/store /nix/store --tmpfs /tmp-home --tmpfs /tmp-run --clearenv --setenv HOME /tmp-home --setenv XDG_RUNTIME_DIR /tmp-run --setenv XDG_RUNTIME_DIR /run/user/1000 --symlink /usr/lib /lib64 --symlink /usr/lib /lib --ro-bind-try /etc/fonts/conf.d /etc/fonts/conf.d --ro-bind-try /etc/fonts/fonts.conf /etc/fonts/fonts.conf --ro-bind-try /home/tomsam/.cache/fontconfig /home/tomsam/.cache/fontconfig --ro-bind-try /home/tomsam/.fonts /home/tomsam/.fonts --ro-bind-try /home/tomsam/.local/share/fonts /home/tomsam/.local/share/fonts --ro-bind-try /var/cache/fontconfig /var/cache/fontconfig --bind-try /home/tomsam/.cache/glycin/usr/lib/glycin-loaders/2+/glycin-svg /home/tomsam/.cache/glycin/usr/lib/glycin-loaders/2+/glycin-svg --setenv XDG_CACHE_HOME /home/tomsam/.cache/glycin/usr/lib/glycin-loaders/2+/glycin-svg --seccomp 24 /usr/lib/glycin-loaders/2+/glycin-svg --dbus-fd 22
         ├─52889 /usr/lib/glycin-loaders/2+/glycin-svg --dbus-fd 22
         └─57740 loginctl --no-pager session-status

Nov 12 22:41:29 warp10 lightdm[1261]: gkr-pam: unlocked login keyring
Nov 12 22:41:28 warp10 systemd[1]: Started Session 2 of User tomsam.
Nov 12 22:41:33 warp10 gnome-keyring-daemon[1669]: discover_other_daemon: 1

seth · 2025-11-13 08:22:09

Looks like an active session (by lightdm, so little chance for a fumbled xinit)

https://wiki.archlinux.org/title/Polkit … ng/logging
What happens when trying to access the device?

tomsam · 2025-11-13 13:04:00

The provider of that rule (producer of that card reader) claims that the device should change from "root root" to "root pcscd", and everything should work fine, i.e. the user gets access to that device without additional udev rules.

And for some reason unknown to me, this seems to be happening in Debian forky. But it might also be that I just haven't found additional udev rules yet (I looked in the common places, and there are no rules that contain the substring pcsc)

With arch, the device stays at "root root" and the pcscd crashes because it cannot access the device.

Last edited by tomsam (2025-11-13 13:04:33)

seth · 2025-11-13 14:15:43

Yes "should" …
The idea is to enable polkit debugging (see the link in my previous post) and see what *actually* happens.

With arch, the device stays at "root root"

That's ok - the polkit rule will allow an action, not change any permissions - it would seem that your invocation of pcscd doesn't involve that action, but we need to see what actually happens.
If there's no access to either org.debian.pcsc-lite.access_* you'd want to strace the pcscd call

strace -f -o /tmp/pcscd.strace pcscd -whatever -and -else …

and post the strace so we can see what it's trying to do instead.

polkit in general works on your system, ie. you can eg. "pkexec ls"?

tomsam · 2025-11-13 15:52:35

Yes, pkexec ls works.

The log output would be

Nov 13 16:37:42 warp10 pcscd[83706]: CYBERJACK: Started
Nov 13 16:37:42 warp10 pcscd[83706]: RSCT: Error on libusb_open: -3
Nov 13 16:37:42 warp10 pcscd[83706]: RSCT: Error on libusb_open: -3
Nov 13 16:37:42 warp10 pcscd[83706]: 00000000 ../PCSC/src/readerfactory.c:1144:RFInitializeReader() Open Port 0x200000 Failed (usb:0c4b/0501:libudev:0:/dev/bus/usb/001/006)
Nov 13 16:37:42 warp10 pcscd[83706]: 00000030 ../PCSC/src/readerfactory.c:371:RFAddReader() REINER SCT cyberJack RFID komfort (1580399470) init failed.
Nov 13 16:37:42 warp10 pcscd[83706]: 00000036 ../PCSC/src/hotplug_libudev.c:527:HPAddDevice() Failed adding USB device: REINER SCT cyberJack RFID komfort

Nov 13 16:37:42 warp10 polkitd[79880]: action=[Action id='org.debian.pcsc-lite.access_pcsc']
Nov 13 16:37:42 warp10 polkitd[79880]: subject=[Subject pid=83705 user='tomsam' groups=tomsam,network,floppy,scanner,power,adm,wheel,audio,lp,optical,storage,video,vboxusers,libvirt,docker,pcscd seat='seat0' session='2' system_unit=null local=true active=true]
Nov 13 16:37:48 warp10 polkitd[79880]: action=[Action id='org.debian.pcsc-lite.access_pcsc']
Nov 13 16:37:48 warp10 polkitd[79880]: subject=[Subject pid=83705 user='tomsam' groups=tomsam,network,floppy,scanner,power,adm,wheel,audio,lp,optical,storage,video,vboxusers,libvirt,docker,pcscd seat='seat0' session='2' system_unit=null local=true active=true]

which shows the failure of opening the device (the libusb_open -3) and the failure of adding the device,
and right after that the two actions.

There are no more log message, and the reader is not accessible after that.

seth · 2025-11-13 16:11:24

org.debian.pcsc-lite.access_pcsc is invoked but it seems pcscd runs as user tomsam and not as user pcscd
You're most likely suppsed to not run that manually as your user but activate usr/lib/systemd/system/pcscd.service or usr/lib/systemd/system/pcscd.socket ?

tomsam · 2025-11-13 16:20:50

No, pcscd runs as pcscd
But of course, I try to access the reader logged in as user tomsam.

sudo systemctl status pcscd.service
[sudo] password for tomsam: 
● pcscd.service - PC/SC Smart Card Daemon
     Loaded: loaded (/usr/lib/systemd/system/pcscd.service; indirect; preset: disabled>
     Active: active (running) since Thu 2025-11-13 16:59:36 CET; 18min ago
 Invocation: 01a0f7bea73044f590206b44812d28b9
TriggeredBy: ● pcscd.socket
       Docs: man:pcscd(8)
   Main PID: 321614 (pcscd)
      Tasks: 8 (limit: 38110)
     Memory: 1.7M (peak: 3.1M)
        CPU: 46ms
     CGroup: /system.slice/pcscd.service
             └─321614 /usr/bin/pcscd --foreground --auto-exit

Nov 13 16:59:36 warp10 systemd[1]: Started PC/SC Smart Card Daemon.

{501} > ps -ef | grep 321614
pcscd     321614       1  0 16:59 ?        00:00:00 /usr/bin/pcscd --foreground --auto-exit

Last edited by tomsam (2025-11-13 16:23:07)

seth · 2025-11-13 21:35:36

The PIDs don't line up

pid=83705
pcscd[83706]: CYBERJACK: Started
Main PID: 321614 (pcscd)

Sanity check, if you change both polkit rules to say

      <allow_any>yes</allow_any>
      <allow_inactive>yes</allow_inactive>
      <allow_active>yes</allow_active>

does it then work?

dimich · 2025-11-14 01:17:57

tomsam wrote:

the producer of my reader tells me that they refuse to provide udev rules, and instead will provide a polkit .policy file that would do all the things (and also set the device's group to pcscd)

I'm not an expert in polkit and smart card readers, but as far as I know, polkit can allow/deny access only to devices managed by another services, e.g. udisks2 etc. It doesn't manage /dev/ nodes.

tomsam wrote:

Nov 13 16:37:42 warp10 pcscd[83706]: RSCT: Error on libusb_open: -3

Libusb works with devices via /dev/bus/usb/ nodes. Error code -3 means LIBUSB_ERROR_ACCESS.

tomsam wrote:

And for some reason unknown to me, this seems to be happening in Debian forky. But it might also be that I just haven't found additional udev rules yet (

libccid in Debian Forky installs /usr/lib/udev/rules.d/92-libccid.rules with a bunch of rules with GROUP="pcscd" for USB devices.

tomsam · 2025-11-14 07:07:16

seth wrote:

The PIDs don't line up
pid=83705
pcscd[83706]: CYBERJACK: Started
Main PID: 321614 (pcscd)
Sanity check, if you change both polkit rules to say
  ...
does it then work?

PIDs don't line up, because it might not be the same moment in time.
Should they be the same anyways? Like any daemon, the pcscd forks itself when it gets real things to do, doesn't it?

"Settings to Yes" does not change anything (Except for pkaction --verbose showing the then actual values)

Last edited by tomsam (2025-11-14 07:48:30)

tomsam · 2025-11-14 07:15:27

dimich wrote:

tomsam wrote:
the producer of my reader tells me that they refuse to provide udev rules, and instead will provide a polkit .policy file that would do all the things (and also set the device's group to pcscd)
I'm not an expert in polkit and smart card readers, but as far as I know, polkit can allow/deny access only to devices managed by another services, e.g. udisks2 etc. It doesn't manage /dev/ nodes.
tomsam wrote:
Nov 13 16:37:42 warp10 pcscd[83706]: RSCT: Error on libusb_open: -3
Libusb works with devices via /dev/bus/usb/ nodes. Error code -3 means LIBUSB_ERROR_ACCESS.
tomsam wrote:
And for some reason unknown to me, this seems to be happening in Debian forky. But it might also be that I just haven't found additional udev rules yet (
libccid in Debian Forky installs /usr/lib/udev/rules.d/92-libccid.rules with a bunch of rules with GROUP="pcscd" for USB devices.

Yes, the device is a USB reader, and I asked here, because the producer of that reader claims that it works for their readers,
and that they will not provide udev rules.

The points are:
* The standard rule file coming with libccid is buggy (both in debian as well as in arch: it has upper case vendor ids, instead of lower case)
* It does not contain my reader in it, and the author of ccid (the same that is responsible for pcscd) refuses to insert my reader in it
* I did not install the libccid package on Debian sid/forky at all.

I checked the common places for rules, and there were no rules that contained the substring "pcsc".

In other words: The udev rules were not there in Debian sid/forky, and still the reader was working.

Last edited by tomsam (2025-11-14 07:16:40)

seth · 2025-11-14 08:50:51

"Settings to Yes" does not change anything (Except for pkaction --verbose showing the then actual values)

Means the polkit check is irrelevant to the behavior.

The udev rules were not there in Debian sid/forky, and still the reader was working.

Ok, then what is the device ownership on debian (screw any specific rule) and what do the polkit logs show there?
And as what user does pcscd run there?

I checked the common places for rules, and there were no rules that contained the substring "pcsc".

But the relevant user/group would be pcscd - not pcsc ?

The standard rule file coming with libccid is buggy (both in debian as well as in arch: it has upper case vendor ids, instead of lower case)

Since those are hexadecimal numbers one would hope that this really doesn't matter at all.

the author of ccid (the same that is responsible for pcscd) refuses to insert my reader in it

Why?

I did not install the libccid package on Debian sid/forky at all.

Then if/why do you on arch? Do you actually use the same frontend to access the cards on bot systems?

tomsam · 2025-11-14 09:11:50

As of the Debian forky version, it seems, I checked too early, because Reiner told me, they would definitely not install udev rules.

But indeed there is a 60-libifd-cyberjack6.rules file. And contrary to the claims of Reiner, it is installed by the libifd-cyberjack6 package, which is the equivalent of the arch pcsc-cyberjack package.
And that explains why the Reader works in Debian forky.

On top, Debian installs a SP17 version, which is not publically available for Download from Reiner, neither for Debian nor as source code (on their webpage it's only SP16).
And unfortunately, I cannot download the source file from the Debian page, either. I asked Reiner to explain this situation.

Yes, I search for pcsc only, because this also covers cases where there is no d at the end.
The hex numbers must be lower case, because for some reasons (as another user said) it's compared to values used with lsusb. Uppercase numbers do not match.

The author thinks, it would not be his responsibility, and others have to provide the rules, especially those who produce the drivers for the readers,
which in turn said that the polkit file only would do the job. He is willing to change the upper to lower case in his ccid rules, but that'd be all.
I stopped writing him, because in the last mail he pointed to a page, where he says, he doesn't like to be contacted, and he asks money for any further explanations.

Yes, it's all the same on arch. I use pcsc_scan or opensc-tool to check for the reader (before I use my other apps)

Last edited by tomsam (2025-11-14 09:12:40)

seth · 2025-11-14 14:52:26

But indeed there is a 60-libifd-cyberjack.rules file. And contrary to the claims of Reiner, it is installed by the libifd-cyberjack6 package, which is the equivalent of the arch pcsc-cyberjack package.

https://aur.archlinux.org/packages/pcsc-cyberjack

And that explains why the Reader works in Debian forky.

So there it'*s root:pcscd/660 ?

Do things now work on your end?

In case and please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

dimich · 2025-11-14 15:40:48

tomsam wrote:

* The standard rule file coming with libccid is buggy (both in debian as well as in arch: it has upper case vendor ids, instead of lower case)

Indeed. I wonder if they ever tested these rules.

tomsam wrote:

* It does not contain my reader in it

Does your device match this rule?

# Generic CCID device (bInterfaceClass = 0x0b)
ENV{ID_USB_INTERFACES}=="*:0b0000:*", GROUP="pcscd"

If it matches, vendor ID / product ID doesn't matter.

tomsam wrote:

* I did not install the libccid package on Debian sid/forky at all.

libccid is a depencency of pcscd package.

tomsam wrote:

I checked the common places for rules, and there were no rules that contained the substring "pcsc".

How did you check? Did you have pcscd installed at that moment?
If it isn't installed but /dev/bus/usb/ node has `pcscd` ownership, this is weird indeed.

What is output of "udevadm info" for your device /dev/bus/usb/... node?

seth wrote:

Since those are hexadecimal numbers one would hope that this really doesn't matter at all.

It does matter. String comparison in udev is case-sensitive. To make it case-insensitive a string must be prefixed with "i", e.g.

ATTRS{idVendor}==i"046A", ATTRS{idProduct}==i"003E" ...

tomsam · 2025-11-14 17:08:02

seth wrote:

So there it'*s root:pcscd/660 ?
Do things now work on your end?

Yes, there the device has root:pcscd and mode 0600
And if I use that file on arch, it's also working.

The point of this whole thread was that Reiner said they would not provide udev rules,
and also claimed that it would work with the policy file only, which apparently is not true.

tomsam · 2025-11-14 17:17:25

dimich wrote:

Does your device match this rule?
# Generic CCID device (bInterfaceClass = 0x0b)
ENV{ID_USB_INTERFACES}=="*:0b0000:*", GROUP="pcscd"
If it matches, vendor ID / product ID doesn't matter.

No, it obviously did not match that rule, otherwise there wouldn't have been problems in the first place.

dimich wrote:

tomsam wrote:
* I did not install the libccid package on Debian sid/forky at all.
libccid is a depencency of pcscd package.

libccid is not a dependency of pcsc-cyberjack, and for pcsclite, ccid it is optional.

dimich wrote:

tomsam wrote:
I checked the common places for rules, and there were no rules that contained the substring "pcsc".
How did you check? Did you have pcscd installed at that moment?

Yes, the pcsclite was installed (the package with the pcscd), but the rule file was brought in by the libifd-cyberjack6 package.
In other words, I forgot to check that again (mainly, because Reiner stated that they would never install udev rules)

I asked the maintainer of the pcsc-cyberjack package to also provide the rules file (like it is done in Debian).

dimich · 2025-11-14 18:04:41

tomsam wrote:

libccid is not a dependency of pcsc-cyberjack, and for pcsclite, ccid it is optional.

Sorry, I misunderstood which case is for Debian and which is for Arch. Nevermind.

tomsam wrote:

The point of this whole thread was that Reiner ... claimed that it would work with the policy file only

They are wrong, I believe.

seth · 2025-11-14 19:38:51

They are wrong, I believe.

"evidently"

tomsam · 2025-11-28 06:53:03

After longer discussions with different people, the necessary rule file 60-libifd-cyberjack6.rules is now provided by pcsc-cyberjack (just as in Debian sid/forky).
Reiner refuses to provide it in their driver packages as long as "their" supported distros do not have pcscd 2.4.0 as their defaults.

Arch Linux

#1 2025-11-12 19:21:13

[SOLVED] Polkit policy file not working, or is the provider wrong ?

#2 2025-11-12 21:21:11

Re: [SOLVED] Polkit policy file not working, or is the provider wrong ?

#3 2025-11-12 21:49:58

Re: [SOLVED] Polkit policy file not working, or is the provider wrong ?

#4 2025-11-13 08:22:09

Re: [SOLVED] Polkit policy file not working, or is the provider wrong ?

#5 2025-11-13 13:04:00

Re: [SOLVED] Polkit policy file not working, or is the provider wrong ?

#6 2025-11-13 14:15:43

Re: [SOLVED] Polkit policy file not working, or is the provider wrong ?

#7 2025-11-13 15:52:35

Re: [SOLVED] Polkit policy file not working, or is the provider wrong ?

#8 2025-11-13 16:11:24

Re: [SOLVED] Polkit policy file not working, or is the provider wrong ?

#9 2025-11-13 16:20:50

Re: [SOLVED] Polkit policy file not working, or is the provider wrong ?

#10 2025-11-13 21:35:36

Re: [SOLVED] Polkit policy file not working, or is the provider wrong ?

#11 2025-11-14 01:17:57

Re: [SOLVED] Polkit policy file not working, or is the provider wrong ?

#12 2025-11-14 07:07:16

Re: [SOLVED] Polkit policy file not working, or is the provider wrong ?

#13 2025-11-14 07:15:27

Re: [SOLVED] Polkit policy file not working, or is the provider wrong ?

#14 2025-11-14 08:50:51

Re: [SOLVED] Polkit policy file not working, or is the provider wrong ?

#15 2025-11-14 09:11:50

Re: [SOLVED] Polkit policy file not working, or is the provider wrong ?

#16 2025-11-14 14:52:26

Re: [SOLVED] Polkit policy file not working, or is the provider wrong ?

#17 2025-11-14 15:40:48

Re: [SOLVED] Polkit policy file not working, or is the provider wrong ?

#18 2025-11-14 17:08:02

Re: [SOLVED] Polkit policy file not working, or is the provider wrong ?

#19 2025-11-14 17:17:25

Re: [SOLVED] Polkit policy file not working, or is the provider wrong ?

#20 2025-11-14 18:04:41

Re: [SOLVED] Polkit policy file not working, or is the provider wrong ?

#21 2025-11-14 19:38:51

Re: [SOLVED] Polkit policy file not working, or is the provider wrong ?

#22 2025-11-28 06:53:03

Re: [SOLVED] Polkit policy file not working, or is the provider wrong ?

Board footer