This can fix autodetection of smart card for Estonian `qdigidoc` https://bodhi.fedoraproject.org/updates/qdigidoc-3.13.5-3.fc27#comment-731189

pcsc-lite will start once software will try to access the card via PCSC (and socket activation). Could you describe what is the issue you are trying to address?

(In reply to Nikos Mavrogiannopoulos from comment #2)
> pcsc-lite will start once software will try to access the card via PCSC (and
> socket activation). Could you describe what is the issue you are trying to
> address?

Hi, Estonia ID card packages (new) co-maintainer here :-)
qdigidoc[1] is a package that allows users to use Estonia ID card to sign documents.
Anatoli Babenia had troubles in using such software because the system did not recognize the card reader. So I suggested him to enable the pcsc-lite service
https://github.com/open-eid/linux-installer/issues/13#issuecomment-363720550

By reading your statement I am assuming qdigidoc is missing something that should trigger pcsc-lite to be enabled on demand. If yes, could you please give me some hints?

Thank you very much

[1]: http://src.fedoraproject.org/rpms/qdigidoc

Thanks for jumping in, Germano. =)

pcsc-lite server is being run once a smart card is accessed by opensc. How does qdigidoc uses smart cards? Does it depend on a crypto lib, or does it handle opensc itself?

If that's the upstream project [0], it seems to be using openssl. In order to use openssl with smart cards one needs to use the engine_pkcs11 as in [1]. If I didn't miss something on that, I believe you should ask the upstream to add smart card support.

[0].
https://github.com/open-eid/qdigidoc/blob/master/crypto/CryptoDoc.cpp

[1].
http://redhat-crypto.gitlab.io/defensive-coding-guide/#sect-Defensive_Coding-HSM-OpenSSL

I am going to ask upstream, thank you

Here is the part that uses pcsc https://github.com/open-eid/qt-common/blob/master/QPCSC.cpp and specific call about service activation:

SC(EstablishContext, SCARD_SCOPE_USER, nullptr, nullptr, &d->context);

I don't see that socket service is started.

[  936.289050] usb 2-1: new full-speed USB device number 4 using xhci_hcd
[  936.422180] usb 2-1: New USB device found, idVendor=076b, idProduct=a021
[  936.422187] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  936.422191] usb 2-1: Product: Smart Card Reader
[  936.422194] usb 2-1: Manufacturer: USB
➜  ~ sudo systemctl status pcscd.socket
● pcscd.socket - PC/SC Smart Card Daemon Activation Socket
   Loaded: loaded (/usr/lib/systemd/system/pcscd.socket; enabled; vendor preset: enabled)
   Active: inactive (dead)
   Listen: /var/run/pcscd/pcscd.comm (Stream)

Feb 23 06:31:05 system systemd[1]: Listening on PC/SC Smart Card Daemon Activation Socket.
Feb 23 06:39:58 system systemd[1]: Closed PC/SC Smart Card Daemon Activation Socket.

I have to start socket.service manually and only then main app starts to work.

➜  ~ sudo systemctl start pcscd.socket
➜  ~ sudo systemctl status pcscd.socket
● pcscd.socket - PC/SC Smart Card Daemon Activation Socket
   Loaded: loaded (/usr/lib/systemd/system/pcscd.socket; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2018-02-23 07:02:29 +03; 2s ago
   Listen: /var/run/pcscd/pcscd.comm (Stream)

Feb 23 07:02:29 system systemd[1]: Listening on PC/SC Smart Card Daemon Activation Socket.

I'm not very familiar with the low-level pcsc code, but if QPCSC::serviceRunning always returns true, does it work?

For what I understand reading https://github.com/open-eid/linux-installer/issues/13#issuecomment-363720550 the problem is that the pcscd service or socket is NOT activated.

So I tried to install pcsc-lite on Centos 7: OK
I build pcsc-tools on the system: OK

But if I execute pcsc_scan I get an error:
$ ./pcsc_scan 
PC/SC device scanner
V 1.5.2 (c) 2001-2017, Ludovic Rousseau <ludovic.rousseau>
SCardEstablishContext: Service not available.

pcscd is NOT started on demand (as it should).

$ systemctl status pcscd
● pcscd.service - PC/SC Smart Card Daemon
   Loaded: loaded (/usr/lib/systemd/system/pcscd.service; indirect; vendor preset: disabled)
   Active: inactive (dead)


I needed to start the pcscd.socket
$ sudo systemctl start pcscd.socket

And then it worked.
$ ./pcsc_scan 
PC/SC device scanner
V 1.5.2 (c) 2001-2017, Ludovic Rousseau <ludovic.rousseau>
Using reader plug'n play mechanism
Scanning present readers...$ systemctl status pcscd.socket
● pcscd.socket - PC/SC Smart Card Daemon Activation Socket
   Loaded: loaded (/usr/lib/systemd/system/pcscd.socket; enabled; vendor preset: enabled)
   Active: active (listening) since ven. 2018-02-23 14:48:42 CET; 1min 27s ago
   Listen: /var/run/pcscd/pcscd.comm (Stream)

Waiting for the first reader... - ^C

$ systemctl status pcscd.socket
● pcscd.socket - PC/SC Smart Card Daemon Activation Socket
   Loaded: loaded (/usr/lib/systemd/system/pcscd.socket; enabled; vendor preset: enabled)
   Active: active (listening) since ven. 2018-02-23 14:48:42 CET; 1min 27s ago
   Listen: /var/run/pcscd/pcscd.comm (Stream)

It looks like the package pcsc-lite does not start the pcscd.socket after installation.

I have not tried on Centos but on Fedora27 it seems to work for me.
```
$ sudo systemctl stop pcscd
Warning: Stopping pcscd.service, but it can still be activated by:
  pcscd.socket

$ pcsc_scan
PC/SC device scanner
V 1.4.25 (c) 2001-2011, Ludovic Rousseau <ludovic.rousseau>
Compiled with PC/SC lite version: 1.8.22
Using reader plug'n play mechanism
Scanning present readers...
0: Nitrokey Nitrokey HSM (010000000000000000000000) 00 00

Fri Feb 23 15:15:42 2018
Reader 0: Nitrokey Nitrokey HSM (010000000000000000000000) 00 00
  Card state: Card inserted, 
  ATR: 3B FE 18 00 00 81 31 FE 45 80 31 81 54 48 53 4D 31 73 80 21 40 81 07 FA
```

socket activation file seems fine to me...
```
$ cat /usr/lib/systemd/system/pcscd.socket
[Unit]
Description=PC/SC Smart Card Daemon Activation Socket

[Socket]
ListenStream=/var/run/pcscd/pcscd.comm

[Install]
WantedBy=sockets.target
```

I made the following test:
1) I disabled and stopped pcscd service;
2) I plugged the USB smartcard reader with Estonia ID card inserted;
3) I opened qesteidutil software, then checked it was correctly reading the card;
4) I opened qdigidoc software, then checked it was correctly reading the card.

Tests passed successfully.

Anatoli we opened this bugreport because I have told you to do that due:
1) you got problems in using the card with qesteidutil + qdigidoc until I suggested you to enable pcscd service;
2) years ago, I had to force pcscd service enable at least on my Thinkpad with embedded card reader.

Actually it looks like pcscd correctly works, so my dubt is if SELinux is creating any troubles on your system.
Could you please attach in a *separate txt file* the output of
# ausearch -m avc

Nikos could you please check also source code of package
https://src.fedoraproject.org/rpms/webextension-token-signing
I tested it on a clean virtual machine and I have noticed that it does not trigger automatically pcscd, so I have to manually start it.
Note: before using it, a user should install firefox-pkcs11-loader package
Best regards

That seems related to systemd enablement of the service and socket activation. The reports are very vague to be able to help with them. If you can figure out something more tangible, I will try to follow up.

I just asked also in upstream mailing list
http://lists.infradead.org/pipermail/pcsclite-muscle/2018-April/001062.html

Hardware activation problem solved!

From http://lists.infradead.org/pipermail/pcsclite-muscle/2018-April/001066.html

==================
Problem solved!
I carefully checked pcsc service and socket systemd unit files,
installed new Fedora and CentOS 7 virtual machines, then tried again.
I found out that once you install pcsc-lite, the command
# systemctl status pcscd.socket
will say that the socket is inactive.
Since on other VMs and machines I found out that the socket was active,
I felt that such incongruence was so strange, then I had a kind of
inspiration and I tought: "mmh perhaps if I reboot the system the socket
will be active?"
I tried, and yes, a simply reboot after pcsc installation, solved the
problem.

Probably running a reload of all systemd unit files will make not
necessary a complete system reboot :-)
==================


I also tried on a new VM the commands

# systemctl daemon-reexec
# systemctl status pcscd.socket

to check if they are enough to let the socket start, but they did not work so I don't know if there is another alternative to complete system reboot or to manual socket start.

If we could find out how we can let the socket start, we could improve affected packages

Thank you for debugging this issue this far. Great to hear that the issue is not with pcsc itself, but the way how it is handled in systemd.

I reassigned this bug to systemd. Can systemd maintainers clarify if this is expected behavior or if there is a way to make systemd socket come up right after installation without waiting for the reboot (since it is already listed in the default preset [1]). There needs to be a way to do that, but packaging guidelines were not helpful for me in this way.

[1] /usr/lib/systemd/system-preset/90-default.preset

(In reply to Jakub Jelen from comment #18)
> I reassigned this bug to systemd

Perhaps we should rename the bugreport title, to make it more compliant to the actual situation


> Thank you for debugging this issue this far. Great to hear that the issue is
> not with pcsc itself, but the way how it is handled in systemd.

I still really don't know how I had the idea make a test about rebooting the entire system :-))

I see pcscd.socket is enabled by default in /usr/lib/systemd/system-preset/90-default.preset. This means that it will be started by default as part of sockets.target, usually at boot.

There is nothing that would start pcscd.socket immediately after the rpm is installed. This is consistent with Fedora Packaging Guidelines. The is no specific rule that starting after installation is not allowed (although I think there was one in the past and got dropped by mistake, it'd probably be worth to investigate this and open an FPC ticket…), but the Guidelines specify that rpms should have certain scriptlets, which in turn indirectly means the same thing.

My recommendation would be to add an udev rule that would trigger pcscd.service when the right hardware is plugged in. If that would be possible, it'd provide the nicest user experience. Otherwise, the only thing is do add some documentation that pcscd.service should be started manually if the service is wanted immediately after the rpm is installed.

I'll reassign this back, since there's nothing for systemd to fix here.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #20)
> My recommendation would be to add an udev rule that would trigger
> pcscd.service when the right hardware is plugged in. If that would be
> possible, it'd provide the nicest user experience. Otherwise, the only thing
> is do add some documentation that pcscd.service should be started manually
> if the service is wanted immediately after the rpm is installed.


IMHO using a udev rule like in upstream article[1] will lead maintainers to start classifying all possible card readers hardware producers, work that is not trivial...

[1]: https://ludovicrousseau.blogspot.it/2010/09/pcscd-auto-start.html

Thank you for the comments. What you say makes sense, but it might not be what the users might expect from automatically enabled services or sockets. When systemd can take care of restarting running services in %systemd_post, couldn't it take care of watching what new default/enabled sockets landed and start them too?

The udev rules were used before https://src.fedoraproject.org/rpms/pcsc-lite-ccid/c/e8896901 , but I am no expert on udev so I am not sure if this would solve the issue.

Also I don't think we would need to enumerate all the devices, since the standard CCID should have specific interface class.

It would be trivial to update the scriptlets to start a service immediately after package installation, without any changes in systemd. The reason this is not done is that generally we don't want package installation to immediately start running services, in case the installation in a mock environment, or some other chroot, etc. I think we might want to change this policy, but this would be subject for a bigger discussion. This policy made sense in sysvinit days, because it was hard to reliably detect if running in a chroot. But nowadays it's fairly easy to check if systemd is running, and if it is, then the service most likely could be started. This has been on my mind for a while, but I haven't yet considered all the edge cases. It's probably something for discussion on fedora-devel.

> Also I don't think we would need to enumerate all the devices, since the standard CCID should have specific interface class.

A rule based on the interface class would be great.

It'd be best to have a smartcard.target, and the udev rule would have ENV{SYSTEMD_WANTS}+="smartcard.target", and pcscd.socket or pcscd.socket would get an additional WantedBy=smartcard.target in the [Install] section.

It would probably be best to avoid starting pcscd through an udev rule as it's only needed when there's a client that wants to talk to pcscd. The hardware being plugged in doesn't mean that the daemon needs to be running.

Starting pcscd.socket from an udev rule makes sense to me though (but not pcscd.service).

(I have been away from smart card stuff for a while so there's a chance things have changed during the last 7 years, but I suspect pcscd activation is still largely the same.)

Hello, I am the upstream maintainer of pcsc-lite.

You do NOT want to have pcscd started when a reader is connected.
You want to have pcscd started when an application wants to use it.

See https://ludovicrousseau.blogspot.fr/2011/11/pcscd-auto-start-using-systemd.html

The solution here is to start the pcscd.service when/after the rpm is installed.
It is strange to have to reboot to have a working system. Unless you want to mimic Windows :-)

OK, that simplifies things. Apart from improving the documentation to give some hints to users, the long-term option would be to change the policy to allow services and sockets to start immediately after installation.

Based on the discussion above, I think that no changes to pcsc are applicable to address that, and we should bring the issue to fedora-devel for further discussion.

Hi Zbigniew, while attempting to make a write-up for the fedora-devel, I'm wondering, whether there is a need for discussion. In the Fedora text on default services [0], it says "Only services that meet the criteria below are permitted to be enabled by default on package installation". That is, the 'package installation' time is quite explicit; there is no reboot requirement, and IMHO
no ambiguity here. After reading that I would have expected services to be operational, on package installation. Should I still start a discussion to Fedora devel or is that sufficient to move that issue to systemd?

[0].
https://fedoraproject.org/wiki/Packaging:DefaultServices

There's a clear distinction between 'enable' and 'start' in this context.

"enable" has a very specific meaning, that of systemctl enable, i.e. creation of symlinks so that the service will be started on reboot (or more precisely whenever multi-user.target is started). It does not mean that the service will be operational immediately.

As for "start", the guidelines do not explicitly say anything about either way. But consider the following:
- the scriptlets that are "blessed" by FPC do *not* start the services [https://fedoraproject.org/wiki/Packaging:Scriptlets?#Systemd]

- there's an old FAQ entry [https://fedoraproject.org/wiki/EPEL:SysVInitScripts?rd=Packaging:SysVInitScript#Why_don.27t_we] that says: > Why don't we....
>    start the service after installation?
>    Installations can be in changeroots, in an installer context, or in other situations where you don't want the services started.

My hypothesis is that the rule to not start services during installation was documented explicitly in the guidelines when sysvinit was used, and then got lost during the transition to systemctl. But current practice is certainly to *not* start the services during installation, as following by a great majority of packages.

To change this, I think the following is necessary:
- make sure that 'systemctl start' properly ignores the request in all contexts where it must be ignored (dnf install --installroot, anaconda, mock, rpm-ostree, etc.).
- modify systemd preset command to support --now, to mean "if enabled in presets, enable and start".
- update %systemd_post to use 'preset --now'.
- update the guidelines to describe the new situation (essentially to say that the service will be started if dnf install is used on a running system and presets specify that the package should be enabled).

What I've done for snapd is do %systemd_post and then test if specific unit I want to start is enabled. If it is enabled, then I start it.

Here's an example: https://src.fedoraproject.org/rpms/snapd/blob/master/f/snapd.spec#_686-696

Adding a link to the discussion on fedora devel mailing list for completeness:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/MJFBGJJMU77NN6C6UVKJHJMSKZZNUSXV/#MJFBGJJMU77NN6C6UVKJHJMSKZZNUSXV

Zbigniew, thank you for the valuable comments and ideas here and in the mailing list. I was not able to follow them in recent month.

This discussion somehow subsided, but the feedback was generally positive, so I believe we should go on with this change for Fedora 29. It will clearly need most of the work on the documentation, addjusting packaging guidelines and systemd side and the minimum on the packages using this functionality.

Would you (Zbigniew, somebody else from systemd?) like to fill a F29 change proposal? If not, I can do it, but I will certainly need some help or at least somebody on systemd side, who could give me a hand there.

Zbigniew how would you like to proceed with that?

This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Sorry for not responding earlier...

> This discussion somehow subsided, but the feedback was generally positive

I would say it was "mixed". I think the idea could be made to work, and people could be
convinced that it's a good change, but I think it'd be a big effort. While I would
like to see somebody do it, I myself cannot commit to the work, I'm behind with
too many things already, and I expect a lot of email traffic and flames if this
change was proposed.

My suggestion would be to do here as in snap, and simply start the the socket or
socket after rpm installation if systemd is running.

pcsc-lite-1.8.25-1.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-fc4bac128f

pcsc-lite-1.8.25-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-c308ad8ee5

pcsc-lite-1.8.25-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-fc4bac128f

pcsc-lite-1.8.25-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-c308ad8ee5

pcsc-lite-1.8.25-1.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.

pcsc-lite-1.8.25-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.