Should udev rules `killall -9 scdaemon` for NEO?

[bradfa]

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:

ACTION!="add|change", GOTO="yubico_end"

# Udev rules for letting the console user access the Yubikey USB
# device node, needed for challenge/response to work correctly.

# Yubico Yubikey II
ATTRS{idVendor}=="1050", ATTRS{idProduct}=="0010|0110|0111", \
    ENV{ID_SECURITY_TOKEN}="1", RUN+="/usr/bin/killall -9 scdaemon"

LABEL="yubico_end"

If it's felt this would be useful, I can make the changes and send a pull request.

[tfheen]

]] 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

[bradfa]

@tfheen, OK. I'll close this, then. Thanks!

[daurnimator]

Where is the issue being tracked with pcscd upstream?

[gdetrez]

@daurnimator There is a (new) gnupg issue here