On 1/29/09, Andreas Jellinghaus <a...@dungeon.inka.de> wrote:
> Am Mittwoch 28 Januar 2009 19:02:39 schrieb Stanislav Brabec:
>
> > In case of Smart Cards, it might be GID writability for "scard" group,
>  > allowing to run smart card daemon without root privileges.
>
>
> if pcscd or openct should run as non-root, then there should be:
>  * one way how openct/pcscd can access the serial and usb devices
>    (please document what users with serial smart card readers need to do)
>  * one way how users allowed to access the readers can connect to openct/pcscd

I added support to openct for multiple groups... So it can be in usb,
serial and smartcard at the same time... The sysadmin should know
which groups needed in order to access the resources.

pcscd runs as root so no issues there.

I try to work with Ludovic in order to create a new reader framework
supported by all of us with the benefit of both openct and pcscd. I
prepare to invest time in separating between the PC/SC API and the
reader access. So that we have one process per reader which is started
by the hotplug service, and PC/SC as a library only implementation.

It will remove the PC/SC daemon, the dependency between reader drivers
and Windows types, the need for threading of PC/SC and much more
legacy.

Something like:
libpcsc->libscreader====RPC====>libscreaderd->reader implementation

This will enable to use the reader in multiple APIs, such as CT or
proprietary using the libscreader.

I closed all the details and I ready to go and implement the
libscreader. But I don't want to reapeat the openct mistake and end up
with yet another competing project. So I need Ludovic on board.

I hope he will approve.

If we succeed the complexity of adding new reader will be somewhat
similar to the complexity of adding a new reader to openct. While the
formal application API may be PC/SC. And the reader framework will be
much more POSIX and hotplug friendly than current IFDH implementation.

>  I think accessing usb smart card readers directly is a very old and outdated
>  design (forgive me for using the word "stupid" earlier), but we can't help
>  if major applications still work that way and know no alternative.

True.
But still there are few scenarios where it make sense, example: firmware update.

Alon.
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Reply via email to