Closed bradfa closed 11 years ago
]] Andrew Bradford
The udev rules could do this for the user by simply adding
RUN+="/usr/bin/killall -9 scdaemon"
. I'm not sure of the security implications of this. Are there any?Would this be a worthwhile change? Or, because it only applies to NEO and not other Yubikeys, should the udev rule break out NEO and treat it differently?
I've tested the following udev rule on Arch Linux and it works, fixing the need to manually run
killall -9 scdaemon
:
We should not do this. The pcscd folks should just fix scdaemon.
Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
@tfheen, OK. I'll close this, then. Thanks!
Where is the issue being tracked with pcscd upstream?
For the Yubikey NEO, when used as a smart card, if you are using the current Yubico udev rules, when you remove the NEO then reinsert, smart card operations that use scdaemon stop working. When reinserting the NEO, scdaemon operations will still not function properly until scdaemon is restarted. One way to restart scdaemon is with a
killall -9 scdaemon
. This problem isn't specific to the NEO, it happens for any openpgp smart card, as far as I can tell.The udev rules could do this for the user by simply adding
RUN+="/usr/bin/killall -9 scdaemon"
. I'm not sure of the security implications of this. Are there any?Would this be a worthwhile change? Or, because it only applies to NEO and not other Yubikeys, should the udev rule break out NEO and treat it differently?
I've tested the following udev rule on Arch Linux and it works, fixing the need to manually run
killall -9 scdaemon
:If it's felt this would be useful, I can make the changes and send a pull request.