adding user to package-forreign group
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
Reply to: