Hi, I am the maintainer of package libchipcard, a library for accessing smart cards. The software is designed in a client/server layout, where the server manages chipcard reader devices and serves requests made by applications willing to access a smart card. The daemon process is running as unprivileged user "chipcard", created by a postinst script.
In order to access ReinerSCT Cyberjack smart card readers a driver package libcyberjack-ctapi2 is needed, which is not in the archive but available on SF.net or the manufacturer's homepage. Unfortunately the driver package restricts access to the kernel device to members of the system group "cyberjack" (using a udev rule). This usually locks the chipcard daemon out. The author of the driver package dislikes to change the name of the group "cyberjack" for rather historical reasons. A clean work around for this (granted minor) problem is, to add the user "chipcard" to the group "cyberjack", which grants access to the kernel device to the system user running the chipcard daemon. Now, after this lengthy previous history, the question is: How can I minimize the work (and also source of errors) to be done by the user to get his Cyberjack chipcard reader running? I am currently thinking about simply adding the user "chipcard" to the group "cyberjack" if this group already exists in the postinst script (current state of work and proposed solution can be found here [1], lines 48 to 54). If I can convince the author (CCed) of package libcyberjack-ctapi2 to do it likewise (i.e. add user chipcard to group cyberjack if this user already exists) I believe this would be a sane solution for this problem. 1. http://svn.debian.org/wsvn/aqbanking/libchipcard3/trunk/debian/libchipcard3-tools.postinst?op=file&rev=455 But prior to releasing the package I am seeking for feedback here, whether that really is a good idea. Is there anything that I missed? Is it okay to mess around with other package's group memberships? Any other comments? Please give me feedback about whether to proceed this way or not. Regards Micha -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
