pcscd: allow configuring power-down and exit timeouts #158
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If auto power-down is enabled, the grace period timeout of 5 seconds is hard-coded. There is no way to disable the feature nor change the timeout without recompiling. However, users may want a longer timeout in order to keep their "session" with the card open (even when no client is connected). For example, the yubikey plugin for the "age" tool has no long-running process; it connects and disconnects each time "age" is run. But using a yubikey PIV which is configurd to require the PIN only once per session is useless, as the session times out after only 5 seconds (after which the user must provide the PIN again). This patch provides a command-line option to set the power-down timeout in seconds. If no option is given, we'll continue to use 5 seconds as the default. Signed-off-by: Jeff King <[email protected]>
The auto-exit feature is hard-coded to exit after 60 seconds. But users who bump the power-down timeout to something higher will want pcscd to keep running, so that the cards may continue to consider it a single session (and so not require the PIN to be input again). Let's add an optional timeout argument to let them set it. We could perhaps guess at this situation by pushing the auto-exit timeout if the a power-down timeout is still running. But it is simplest to just let the user configure the two independently. Signed-off-by: Jeff King <[email protected]>
|
wrong solution to the problem. |
|
See my comment in str4d/age-plugin-yubikey#144 (comment) |
|
OK. I don't love the external-script option you presented in that age issue, and I do think that these options are potentially useful even independent of the problem I was solving. But at the same time, I can see how they might introduce extra complications, and certainly if your opinion is that they're useless and/or ugly, I don't think it's worth debating further. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've recently started using a yubikey PIV; the device is configured to require the PIN once per session. But since the tool I use it with (
age) does not keep a long-running connection topcscd, a "session" only lasts 5 seconds until the device is auto-powered off. Likewise, even if that timeout is bumped, thenpcscdstill auto-exits after 60.The problem is discussed in more detail in str4d/age-plugin-yubikey#144.
Here are two patches to allow the user to bump those two timeouts. I'm using it with on my Debian system by putting
PCSCD_ARGS="--auto-exit=86400 --power-down-timeout=86400"into my/etc/default/pcscdfile.This certainly solves my problem. I'm not sure what the drawbacks might be, aside from presumably some extra power draw to keep the device powered. That's not a big deal for my use case, but it may mean that it's not a good general solution. Still, it seems like this is just giving users more run-time options (without having to rebuild the daemon themselves), which is probably a good thing.