XRDP smartcard passthrough via windows RDP client

[briantownjr]

Base setup of xrdp with all passthrough options selected in the Windows 10 RDP client.
Remote host Ubuntu 20.04
xrdp version 0.9.12

Perhaps I missed something in setup but I didn't see any options for including RDP devices, when I remote into the client the system is unable to read any mapped devices or drives.

[matt335672]

Couple of things:-

• Smartcard passthrough doesn't work well enough for production yet. We've got some architectural changes to make this work adequately.
• xrdp v0.9.12 has a bug (Clipboard and drive redirection are broken when "Printers" is selected as a shared local resource #327) which means if you've got printer sharing enabled you won't be able to see any remote drives. Disable the printer sharing on your client and the remote drives should work OK.

[ibeckermayer]

I've been researching xrdp smartcard support, and I'm a bit confused about what's being asked here.

My current understanding is: xrdp does have smartcard support -- if I dig into the codebase I see what looks like an implementation of MS-RDPESC. However I also see questions like this, and long-open PRs like #963 and #1825. From what I can tell, these are asking for support for passing smartcard through to/from PCSC over a socket.

Is this understanding correct? Or is there some important context that I'm missing? Thanks in advance for anybody who can help to clarify.

[matt335672]

Hi @ibeckermayer

Funnily enough I'm just starting to look at this. I wasn't involved with the original development, but my understanding of the situation is as follows:-

• The original plan was to develop a replacement for libpcsclite.so. This changed around 2016 - see use existing pcsc library instead of building replacement #471. The current plan it to redirect PCSCLITE_CSOCK_NAME within xrdp sessions to a socket which chansrv is listening on. chansrv will then provide an implementation of the pcscd daemon which will interface to [MS-RDPESC]
• The existing codebase in devel never completely made the transition to the current idea - see set PCSCLITE_CSOCK_NAME env var #963
• In 2021, @zorgluf attempted to pick this up in Smartcard implementation with PCSCLITE_CSOCK_NAME #1825. I ended up not having the time at that point to look at what he's done so that attempt failed too. That's down to bad planning on my part.

That's the history. Here are some other points:-

• Although this planned architecture will work for some versions of pcsc-lite, we're making use of another project's private interfaces. This isn't a great idea for long term stability - see for example this comment and this comment. We will need to engage with @LudovicRousseau to make sure this can be made stable in the long-term.
• The interface to [MS-RDPESC] is somewhat different from the other RDP interfaces in that it's based in DCE IDL structures. Converting these to the corresponding network data representations is quite fiddly without an IDL compiler, but even more fiddly with one, from what I can see.
• There's clearly a lot of interest in getting something working.

While I'm waiting for some other changes to get merged I'll pick this up and see how far I can get with it.

[ibeckermayer]

@matt335672 thank you so much for this detailed reply.

Although this planned architecture will work for some versions of pcsc-lite, we're making use of another project's private interfaces. This isn't a great idea for long term stability - see for example this comment and #1825 (comment). We will need to engage with @LudovicRousseau to make sure this can be made stable in the long-term.

Makes sense to me.

The interface to [MS-RDPESC] is somewhat different from the other RDP interfaces in that it's based in DCE IDL structures. Converting these to the corresponding network data representations is quite fiddly without an IDL compiler, but even more fiddly with one, from what I can see.

Presuming I'm not getting my acronyms jumbled up, I believe that the DCE IDL structures are ultimately compiled down into NDR octet streams. In implementing [MS-RDPESC] for the client side our approach has been to essentially do each of these by hand, which is based on the approach taken by FreeRDP. (Maybe you can literally copy much of the FreeRDP implementation).

There's clearly a lot of interest in getting something working.

Over at Teleport we're seeing some demand for this feature gravitational/teleport#13179, hence my interest.

[LudovicRousseau]

I am not sure to understand what you are trying to do.
The protocol over the socket that can be redirected using PCSCLITE_CSOCK_NAME environment variable is NOT documented or supposed to be used by something else than pcscd and libpcsclite (and using the same version and configuration).

Maybe I can help?

[ibeckermayer]

@matt335672 excellent work, following this closely.

2. @jsorg71's stub library in sesman/chansrv/pcsc/xrdp_pcsc.c is modified to pull in <pcsclite.h> so we get compile-time checking of the stub functions.

If I'm following along correctly I think <pcsclite.h> may be the wrong include. See the documentation here for a very helpful overview of how things fit together. I believe it's winscard.h that we'd want to pull in, which represents the api exposed by libpcsclite.so.1 and which we want to implement in xrdp_pcsc.c. @LudovicRousseau can you confirm if this understanding is correct?

4. At runtime (if we're built with -with-libpcsclite), we set the variable XRDP_LIBPCSCLITE_SOCKET to point to a UNIX socket, and prefix LD_LIBRARY_PATH with ${libdir}/xrdp-pcsc

Just to double check my understanding: the idea here is that for each winscard API call in xrdp_pcsc.c (like SCardEstablishContext), we take the call, convert it to its corresponding [MS-RDPESC] call and then send it to the main xrdp process which will be listening on this XRDP_LIBPCSCLITE_SOCKET socket and which will pass it over the rdp connection to the rdp client. Then, once xrdp receives an [MS-RDPESC] response from the client, it will send that back over the XRDP_LIBPCSCLITE_SOCKET socket which xrdp_pcsc.c will be listening on, and which will subsequently return from the original call.

This looks promising to me as we're using a public API.

Agree in general this is a better approach.

[LudovicRousseau]

@ibeckermayer is right. The WinSCard API is defined in the winscard.h header file. pcsclite.h should not be used by applications.

If you want to use a very simple PC/SC sample code for your tests you can use https://blog.apdu.fr/posts/2010/04/pcsc-sample-in-c/

[matt335672]

Thanks all. I'll remove the pcsclite.h header. I'll look at the test program once I've figured out how all the plumbing will work.

@ibeckermayer - That's right apart from one small detail. It also raises an important point about the existing design which is useful to understand at this stage.

We have a component called xrdp-chansrv which runs as the logged-in user and is responsible for file system redirections and the clipboard. This will handle the XRDP_LIBPCSCLITE_SOCKET. There's a limitation in this, which is that the smartcard won't be available to authenticate the user. We can address this later on by moving the code to a library which is shared with xrdp.

@briantownjr - I'm still learning about this area. Can you elucidate on what you mean about opensc-pkcs11.so? Is this something that can use libpcsclite.so.1, or are you suggesting replacing it with another stub?

@LudovicRousseau - With your experience in this area is there any benefit in implementing full UTF-8 support rather than just ASCII?
[MS-RDPESC] defines both ASCII and UTF-16 interfaces. We have Unicode conversion routines in xrdp which I can use to provide full UTF-8 support if there's any benefit in doing so.

[ibeckermayer]

We have a component called xrdp-chansrv which runs as the logged-in user and is responsible for file system redirections and the clipboard. This will handle the XRDP_LIBPCSCLITE_SOCKET. There's a limitation in this, which is that the smartcard won't be available to authenticate the user. We can address this later on by moving the code to a library which is shared with xrdp.

Hmm, yeah good catch, seem necessary to change that to really make full use of smartcards. At least, I'm aiming to use it for user authentication.

Though I'm also considering whether it's possible to authenticate with a certificate in some other way, since in practice the tool I'm working on (https://github.com/gravitational/teleport) is just using a virtualized smartcard as a means of presenting a certificate for auth, but any cert-based authentication would work for us in theory.

[MS-RDPESC] defines both ASCII and UTF-16 interfaces. We have Unicode conversion routines in xrdp which I can use to provide full UTF-8 support if there's any benefit in doing so.

@matt335672 in my experience from building [MS-RDPESC] clients, Microsoft's default RDP server only sends the *W* (UTF-16) versions of [MS-RDPESC] PDUs. Consistently enough that we've in fact only implemented those in our client and ignored the ASCII versions, without running into any problems in the wild.

Edit: Ahh interesting, I just noticed @LudovicRousseau suggests the opposite decision: #2625 (comment).

The main argument I can see for Unicode (beyond "that's what Microsoft seems to do") is that perhaps foreign reader hardware requires it, i.e. if the reader name is in Chinese characters. I have encountered such issues in implementing directory sharing ([MS-RDPEFS], of which [MS-RDPESC] is a subset).

[matt335672]

That's very useful - thanks.

I'll get the smartcard functionality working on the desktop first, as I'm not at all up to speed in this area yet. After that it should be clearer to me how to move the channel functionality away from chansrv.

[LudovicRousseau]

@matt335672 ASCII should be enough.
Even if I played with reader names in Unicode I have never seen such a name in the "real" world.

[matt335672]

Small update - there are a few dragons around using the LD_LIBRARY_PATH in a session. See for example, Debian BTS #711623. There are, as ever, workarounds but they may be quite specific.

For now, I'm providing an XRDP_LIBRARY_PATH in addition to the LD_LIBRARY_PATH. On awkward systems, LD_LIBRARY_PATH can be re-initialised from XRDP_LIBRARY_PATH if running in an xrdp session. There are probably better solutions to this.

I see also from this bug report that other commercial software is using this approach.

[LudovicRousseau]

In another discussion I proposed that the RDP server implements and replaces libpcsclite.so.1 to solve this problem.

The side effect is that it would not be possible to install xrdp and libpcsclite (from pcsc-lite) at the same time on the system. The 2 packages would conflict with each other.

I don't know if you have a use case with a RDP server that have a locally connected smart card reader and would need pcsc-lite installed on the server.

[matt335672]

Yes we do, sadly. The use-case is above. I can't blame you for missing it - github seems to be very good at hiding things which are quite important. Perhaps it's just the way I use it.

The use-case for a pure Linux RDP server (which is what you have in mind) can be met in a couple of ways:-

1. By providing an xrdp-pcsclite package which conflicts with libpcsclite

2. by using ldconfig. The workflow is as follows:-

   1. Server is built in the usual way. xrdp package is installed explicitly. libpcsclite is pulled in from dependencies.
   2. System admin uses ldconfig to prefix an xrdp library directory to the shared library search path.
   3. All utilities now pick up the xrdp implementation of libpcsclite.so.1

   This should work for at least Debian and RHEL derivatives. Packaging scripts for both need to ensure the xrdp-provided library is not advertised by the package.

The more general use-case needs the library which is loaded to be changed at run-time. The LD_LIBRARY_PATH approach is fiddly for this, but can work. I don't have a better idea at the moment.

[LudovicRousseau]

OK I see the use case.
Another option is to have a libpcsclite.so.1 wrapper that redirect the calls to either the real libpcsclite.so.1 or to another library provided by xrdp.

For example see how the PC/SC spy works https://blog.apdu.fr/posts/2022/06/pcsc-api-spy-update/
The install_spy.sh script modifies the files on disk.

[matt335672]

That looks really useful - thanks. I can see what's happening there.

xrdp has to support a large number of combinations of desktops and their supporting environments. Because using LD_LIBRARY_PATH has security implications, I can see that using LD_LIBRARY_PATH is going to result in a steady trickle of support calls as security postures and attitudes evolve over time.

I think your approach is more complex to implement, but it's going to be a lot easier to support in the long run.

That's just my opinion though. Anyone else got any comments?

@CendioOssman - is any of this any use to you? I see you have some experiences in this area.

[CendioOssman]

I have not been involved with any xrdp stuff, so I'm not sure how I got connected here. :)

But we do something similar to what you discuss here in ThinLinc, using LD_LIBRARY_PATH. Having a more clean multiplexer between PC/SC libraries would definitely be interesting to us.

[matt335672]

My apologies @CendioOssman - I read this bug report you created a while ago, and just thought you might be interested in the discussion.

[CendioOssman]

No worries. The issue seems to grow to something wider than just xrdp, so it sounds like something I should be involved in. :)

[LudovicRousseau]

I opened an issue at PCSC project to discuss what can be done in pcsc-lite: Delegate WinSCard calls to another libray (for a RDP server for example) #161
I propose to explore technical solutions (for xrdp, ThinLinc, etc.) there.

[matt335672]

@jsorg71 - I'd appreciate you looking at the above linked issue if you have time. You've got a lot more experience than I have in this area.

[jsorg71]

My comments here as I did most of the work on what we have now.
We are stuck with 2 not so nice options here. Replace the libpcsclite libraries or use the pcscd standin with PCSCLITE_CSOCK_NAME environment variable. Maybe we can find another solution but we would need Ludovic’s cooperation.

No one likes the replace method so I worked on the pcscd standin.

To describe how the pcscd standin works, I’ll define "pcscd com." This is the private pcscd – libpcsclite unix domain socket communication. The one that is not publicly documented or supported.

It’s true, the pcscd com is not 1 to 1 mapping of the PCSC calls. I works in a way that is actually beneficial to xrdp. Most of the calls like connect, transmit, control are direct calls but the way list readers and get status change difffer. There is a map of 16 readers that pcscd returns to libpcsclite.
xrdp(chansrv) does a list readers and get status change on the client with an INFINITE timeout so it updates the map of readers when something changes. The reason this is beneficial to xrdp is that a lot of app constantly query / poll the reader state. The saves a bunch of traffic to the client. Not really big traffic but lots of small round trips. If we have to create your own library again, I think we should just fork libpcsclite so we know the details of pcscd com. Pcscd com does have a version number as one of the first messages so we could look use that.

We do already "unsupported" things like the out of tree modules for pulseaudio.

Maybe another solution is pcscd could add support for drivers or modules. I think projects like pcsclite and pulseaudio don’t want to support these plugable modules because it is of course more work for them. It’s perfectly understandable.

[matt335672]

That's a reasonable summary of the current xrdp situation I think.

I think we're all agreed that using PCSCLITE_CSOCK_NAME from xrdp with the existing PCSC-Lite software isn't a sensible way forward as that interface is private to PCSC-Lite, and it's unreasonable to expect that to change.

That would seem to give us these options:-

1. Fork a particular version of the existing PCSC-Lite libpcsclite.so.1 and add it into xrdp.
2. Update the existing shim library to look like libpcsclite.so.1 and pass calls through it to chansrv and on to the client using [MS-RDPESC].

Both of these solutions require libpcsclite.so.1 to be replaced. That would be done either by using LIBPCSCLITE_DELEGATE as outlined in LudovicRousseau/PCSC#161 or by providing a similar facility on the xrdp side, and using ldconfig to force the xrdp library to be picked up first. I don't think either of those should be that complicated to implement.

Solution 1) is more complex (i.e. more code to maintain) but should offer the best performance. Solution 2) won't be as performant but should be simpler to maintain. So we need some way to choose between them.

Is that a reasonable argument? Have I missed anything?

[jsorg71]

Yes I think so. I am concern about using LD_LIBRARY_PATH though. Will both these options allow disconnect / reconnect?

[matt335672]

We're not using LD_LIBRARY_PATH. I tried that and it's not a great idea in 2023. My comment in the other thread has some more details on how I currently think this could work.

Disconnect/reconnect needs to be handled in chansrv for both options doesn't it? Or am I misunderstanding what you are asking?

[LudovicRousseau]

@jsorg71 what do you mean by "pcscd could add support for drivers or modules"?
What would a driver or module do?

[jsorg71]

For module or driver, I'm think more like pulseaudio or Xorg. For each session, we run an Xorg server and a pulseaudio server. In a normal desktop mode, Xorg and pulseaudio talk to the hardware through a driver. In the case of an xrdp session, Xorg and pulseaudio talk to xrdp through a different driver. Here the term driver or module really are just userspace so files.
So if we could run a pcscd for each session and have it not use the hardware and use a module we provide.
I don't know all the details of pcscd but I guess that is big change.

[matt335672]

@jsorg71 - can you tell me how you see the user experience for disconnect/reconnect working?

At the moment devredir.c doesn't seem to have any visibility of client disconnects. As a result, active IRPs will hang if a client goes away unexpectedly. This would include any active SCardGetStatusChange calls. It's easy enough to add the plumbing to chansrv so that devredir.c can clear up active IRPs on a disconnect, but it's not clear to me what we're aiming for from a user perspective.

At the moment I'm playing with option 2) above. I'm using your xrdp_pcsc.c code with a few changes to talk to a re-worked chansrv which just passes the calls up though the RDPDR channel. It's got the advantage that there's not a lot of state information to keep track of so it should be easy enough to get working and get the code reasonably well structured.

The current disadvantages I'm aware of:-

1. It's not clear at all what performance will be like.
2. If there's no client, EstablishContext can't be done.
3. If the client disconnects, any active calls will need to be failed with a suitable error (e.g. SCARD_E_SERVICE_STOPPED, or SCARD_F_COMM_ERROR).

Some or all of these disadvantages can be addressed by adding more state data to chansrv, but as I said, it's not clear to me exactly what we're aiming for.

From a maintenance perspective I quite like the idea of resurrecting xrdp_pcsc.c. Whatever we use for a shared library will be a little different from the rest of the xrdp code, but using xrdp_pcsc.c keeps the footprint of this code pretty small.

[jsorg71]

Yes, on disconnect, the IRPs need to fail. I think when an IRP is sent to client, it's put in a list to use when it returns. We should use them on disconnect to error out. There was something in there for this but maybe only for the smart card calls.
If we are going the use the delegate thing, yea we should use xrdp_pcsc.c or write something like it.
I think I did expand and use virtual card readers with the "stand in" approach so then EstablishContext did work even without a client which I think I needed for Chromium.
I think we can do something like this too at the pcsc layer and not worry about that in RDPDR even with the delegate solution.

I did bring up the issue at RDPIO. What should happen when the client disconnects? Do you lose all the cards? Do you lose all the card reader? Are they still there but just error out until reconnect? I did not get an answer and I didn't test on MS to MS RDP session to find out. So there is some unknowns here.
It's amassing how bad the whole stack is with PCSC even without xrdp. Chromium for example will not use smartcards unless they are there when it starts. Even if the reader is there, then removed, then added back, it will never work again. That is why I did the work on the virtual readers.

[ibeckermayer]

@matt335672 @jsorg71 has there been any further development for this feature?

[matt335672]

@ibeckermayer - I've been looking at re-engineering a replacement for libpcsclite.so, but it's fairly slow work, and at the moment we've got a sponsored activity we're all busy with. It's something I'll be coming back to as soon as I can get to it.

[frankmorgner]

with the risk of being too late to the party: at xrdp, have you thought about deploying a virtual smart card reader at the server side instead of replacing the existing libpcsclite.so? That would also work on macOS. At the other side, a normal PC/SC client would do. I have implemented this here http://frankmorgner.github.io/vsmartcard/pcsc-relay/README.html

The only limitation would be that you cannot adjust the name of the virtual reader to match the name of the read smart card reader, because that is defined at the time when the driver of the virtual reader is loaded.

[matt335672]

@frankmorgner- thanks for joining the discussion and providing the (interesting) link. Up until now I hadn't considered such an approach.

There's been some progress on LudovicRousseau/PCSC/#161. I'm currently using a pre-release of this to test my own developments, which are reasonably encouraging so far.

The current architecture we've got is that LIBPCSCLITE_DELEGATE points to a library which is part of xrdp. This library marshals the PCSC lite calls over a session-specific UNIX domain socket connection to the xrdp channel server which provides the interface to the DCE type conversions.

The advantage of this technique is that the smartcard redirection can be fairly easily restricted to a single session - it's not clear to me that this would be the case for a virtual smartcard(?) - xrdp can support multiple sessions per user on non-systemd systems.

As you point out, a disadvantage of this technique is that MacOS support is dependent of the user compiling a later version of PCSC-Lite. In practice, on Linux systems, this may well be the case as well, at least in the short-term.

I'm planning on documenting the socket interface, so it should be a simple matter to provide a virtual reader which would use this interface, giving us the best of both worlds. If we did things this way, your use of GPL and our use of ASL shouldn't pose any problems.

[frankmorgner]

@LudovicRousseau work was what let me here in the first place. Although the modifications of PCSC-debug look fairly simple, I was in doubt if we really need a different way of debugging PCSC-Lite, let alone the problem that modifying an environment variable to gain access to PIN APDUs for a smart card seems to be fairly easy from an attacker's point of view...

I assume that when and if LIBPCSCLITE_DELEGATE goes into production, I would understand if you'd use it, because it allows you directly executing RDP's WinScard commands in PCSC-Lite without any emulation. Note that macOS nowadays doesnt use PCSC-Lite anymore, but a proprietary implementation of the PC/SC frame work, that will likely not support LIBPCSCLITE_DELEGATE any time soon.

A virtual reader on the server's side allows using the PC/SC framework of the server's machine without any modifications, that's why you could use the server also on macOS and even on Windows (vpcd from above also has a Windows implementation). The virtual reader would appear as if it was physically connected to the server's machine. I don't know if it is possible to limit a (virtual hardware) device's usage to a specific user, but I would assume it is possible.

The TCP/IP interface to my virtual driver is very simple, which is why it has been used for different other applications as well and why it has found its way into some distributions. Yes, using my interface imposes no licensing requirement on your side. But actually, you don't necessarily need to use my driver, but you could also implement the interface in reader.h for your own driver to communicate to xrdp directly.

[LudovicRousseau]

Using a virtual reader is a nice idea. @frankmorgner Please confirm I understand correctly.

• ifd-vpcd is a pcsc-lite driver that will redirect the communication to a remote reader.
• the virtual driver is configured using a /etc/reader.conf configuration file to give the remote host VPCDHOST address.

So it is not easy to dynamically add/remove virtual readers. You need to edit /etc/reader.conf and ask pcscd to reload its configuration
If you have 2 RDP sessions on the same server you would have 2 virtual readers on the server. All applications on the server and also the RDP client will see 2 virtual readers (and also the physical readers connected on the server if any).

Did I missed something?

[frankmorgner]

Yes, ifd-vpcd is loaded by pcscd as serial reader by the use of /etc/reader.conf. The only required data in reader.conf is the FRIENDLYNAME and LIBPATH so that pcscd knows where to look and what string to use for the virtual reader. DEVICENAME (or CHANNELID as fallback) is used as optional configuration parameters of the driver. DEVICENAME localhost:0x8C7B lets vpcd open a port locally and wait for incoming connections whereas DEVICENAME 192.168.0.14:0x8C7B connects to an already running virtual smart card ("reversed mode").

Yes, I don't see an easy way to add/remove readers without restarting pcscd. Also, I am not aware of a mechanism that allows the reader driver, i.e. ifd-vpcd, to detect the user (session), from an SCARDCONTEXT. If that mechanism existed, it would be possible to tie limit access to the card to a specific RDP session even though the virtual reader (and possible ATR) would have global visibility by the system's pcscd.

[matt335672]

I've been looking at the code for PCSC-Lite, and (if I understand it correctly) one way to make this work with separation of sessions would be to start a session-specific pcscd in the context of the user with --disable-polkit and a private reader.conf. It doesn't solve the dynamic adding and removal of cards though, and it may be a use-case the daemon is not currently anticipating.

Does that sound right @LudovicRousseau or have I missed something too?

Once again, thanks @frankmorgner for provoking an interesting discussion.

[LudovicRousseau]

It may be possible to start one pcscd per RDP session and play with --disable-polkit, --config and PCSCLITE_CSOCK_NAME to have a user defined PC/SC configuration (and run pcscd as a normal user instead of root).
Smart card insertion/removal is simulated by ifd-vpcd.
The other side of vpcd (vpicc?) must be connected somehow to the RDP server.

It is more complex than using LIBPCSCLITE_DELEGATE but it could work with the current pcsc-lite code.

[frankmorgner]

we opted early for internet sockets for better interoperability

[matt335672]

So for an RDP server with potentially several sessions, the flow would go something like this at the RDP server:-

1. Starts session.
2. Starts ephemeral listening TCP port (bound to 127.0.0.1 or ::1)
3. Set PCSCLITE_CSOCK_NAME to a suitable location for pcscd to communicate with its clients.
4. Create a reader.conf for PCSC-Lite pointing to the ephemeral port (in reversed mode)
5. Start pcscd in the user context, probably with --disable-polkit and --config switches.

In ASCII art:-

+------------------+   (uses PCSCLITE_CSOCK_NAME)   +---------+
| libpcsclite.so.1 | -----------------------------> | pcscd / |   <--- (reader.conf points to ephemeral port)
+------------------+                                | vpcd    |
                                                    +---------+
                                   (uses ephemeral port)|
                     [RDP Server] <---------------------+

Using reversed mode avoids a race condition where we create the config file with a particular port and then hope the right application binds to us.

I've not provided unnecessary detail about the RDP server.

Does that look about right so far?

[frankmorgner]

LGTM: one pcscd for each user (session), each loaded with its own virtual reader driver, that is connected to the RDP server. The RDP server then forwards this connection to the RDP client, which acts as PC/SC client on the client's machine.

[LudovicRousseau]

After re-reading the source code of pcsc-lite I see it will NOT work. Sorry.
PCSCLITE_CSOCK_NAME env variable is used on the libpcsclite.so.1 side only.
On pcscd side the value is a #define. So you would have to rebuild pcscd for each different value of PCSCLITE_CSOCK_NAME you want to use.

I would have to modify pcsc-lite to use getenv("PCSCLITE_CSOCK_NAME") also in pcscd side.
If pcscd has to be modified (and deployed) it is simpler to use LIBPCSCLITE_DELEGATE instead.

[matt335672]

I apologise too - I misread the source code when I put the above proposal together.

I don't see that the above proposal makes more sense than using LIBPCSCLITE_DELEGATE, at least not for our use-case. The reason I posted it was as a starting point for discussions. Can it be improved on in any way @frankmorgner ?

[LudovicRousseau]

LIBPCSCLITE_DELEGATE is now implemented in pcsc-lite 2.1.0
See https://blog.apdu.fr/posts/2024/04/how-to-use-libpcsclite_delegate/

It is now the job of the xrdp project to use this new pcsc-lite feature.

Unfortunately there is no easy way to know if LIBPCSCLITE_DELEGATE is supported or not.
I suggest to parse the first line of the output of /usr/sbin/pcscd -v to extract the version:

$ /usr/sbin/pcscd -v
pcsc-lite version 2.1.0.
Copyright (C) 1999-2002 by David Corcoran <[email protected]>.
Copyright (C) 2001-2022 by Ludovic Rousseau <[email protected]>.
Copyright (C) 2003-2004 by Damien Sauveron <[email protected]>.
Report bugs to <[email protected]>.
Enabled features: Linux x86_64-pc-linux-gnu libsystemd serial usb libudev polkit usbdropdir=/usr/lib/pcsc/drivers ipcdir=/run/pcscd filter configdir=/etc/reader.conf.d
MAX_READERNAME: 128, PCSCLITE_MAX_READERS_CONTEXTS: 16

[matt335672]

Thanks @LudovicRousseau

We are using the development headers of pcsc-lite to check the function prototypes at build time, so we can add a version check in at this point.

[LudovicRousseau]

You should check at run time instead of at build time.

I may remove PCSCLITE_VERSION_NUMBER from pcsclite.h in a future version.
So I do not recommand using this #define.

[matt335672]

OK - thanks.

[es-fabricemarie]

@matt335672 is there any update on this topic?

We have a lot of demand for this feature. We'd be happy to sponsor the effort.

[matt335672]

Hi @es-fabricemarie

At the moment, there's no update. We're quite busy on another sponsored feature at present, which is getting H.264 and NVENC finished.

[matt335672]

I'll talk to the team and see what scope we've got for moving things around.

[matt335672]

@es-fabricemarie - once we've got a delivery for NVENC, we'd be able to get some effort available for this development, if some sponsorship is available.

When you say "we have a lot of demand for this feature", who is "we" exactly? PM me on Gitter if you want to take this conversation offline.

[es-fabricemarie]

@matt335672 I've tried to ping you repeatedly including transfering you ownership of a dummy github repo with my contact.
I'm now on gitter but I can't seem to find you. Please ping me @es-fabricemarie:gitter.im