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