[Pcsclite-muscle] Support for file-descriptor based devices in pcsclite

[Ludovic Rousseau]

Le jeu. 9 juin 2022 à 08:57, Wiktor Kwapisiewicz <wiktor at metacode.biz> a écrit :
>
> Hi Ludovic,

Hello Wiktor,

> The additional difficulty is that I wasn't able to find out how to get
> the USB device file descriptor on desktop Linux (I think you mentioned
> that this should be possible) so my work was done only on a phone
> (including writing, compiling and testing). Sadly Android has a
> different file layout than a regular Linux and (from my understanding)
> running a daemon that listens on non-standard Unix socket path (*not*
> /var/run/pcscd/pcscd.comm) would require also to compile the client
> library to also reference that non-standard path.

You can use the environment variable PCSCLITE_CSOCK_NAME to indicate
the socket name you want to use
See https://ludovicrousseau.blogspot.com/2010/11/pcsc-client-and-server-on-two-different.html

My initial idea was to open the USB device in src/hotplug_libudev.c.
And then give the file handler to the driver.
The device is already found by the pcscd hotplug mechanism so we do
not need to rescan the USB bus in the CCID driver.

The problem is different on Android since you get the file descriptor
from *outside* of pcscd.

> > I propose to add a new function in the IFD Handler API.
> > https://pcsclite.apdu.fr/api/group__IFDHandler.html
> >
> > Something like:
> > IFDHCreateChannelByFd(DWORD Lun, int FileDescriptor)
> >
> > Then you can use libusb_get_device() to get a libusb device structure
> > from the file descriptor.
> > I expect some code refactoring in CCID src/ccid_usb.c to avoid
> > duplicating a large part of OpenUSBByName()
>
> Thanks for your pointers! I've been looking at the code but
> unfortunately got stuck in hotplug_libusb.c that, ultimately, I figured
> out would not be needed since hotplug manages device additions and
> removals and USB file descriptor represents a ready device.
>
> One additional problem: at least on Android there's an utility program
> that grabs the device and passes the file descriptor to another program.
>
> An example: termux-usb -e ./usbtest /dev/bus/usb/001/002
>
> This runs "./usbtest" with one argument: numeric parameter representing
> the file descriptor (e.g. "./usbtest 7"). The question is should pcscd
> be extended with an argument that it would use?

On Android it may be possible to start pcscd only when a smart card
reader is connected.
So the device file descriptor could be a new pcscd argument.

On a desktop, pcscd is started when the application calls
SCardEstablishContext()
See https://ludovicrousseau.blogspot.com/2011/11/pcscd-auto-start-using-systemd.html

So pcscd may be already running when a new smart card reader is
connected and need to be added.
We must find a way to transfer the file handle to a running pcscd.

I guess Android does not use systemd. So the auto start of pcscd is
not possible on Android.

One solution would be to split pcscd in two processes:
- one process H (for hotplug) is in charge of hotplug and opening the
device (on linux)
- one process P (for pcscd) is doing the other jobs of pcscd (resource
manager between applications and readers)

The interprocess communication between H and P could be reused on
Android to transmit the new reader file handle to P.
One benefit is that P does not need to be run as root. It could be
process with low privileges.
It could help solve "Use systemd to restrict pcscd rights"
https://salsa.debian.org/rousseau/PCSC/-/issues/10

> Also, if you have an idea on how could I test that on a regular desktop
> Linux distribution it would be super-helpful as debugging it on a phone
> is really inconvenient.
>
> So: sorry for the delays but I can't currently spend the amount of time
> I would like to on this :(

No problem.
Take your time.

I understand the task is more complex than I initially thought.

Bye

-- 
 Dr. Ludovic Rousseau