Notify card driver that Reader lock obtained and if card was reset #842
Conversation
During sc_lock, if card->reader->ops->lock is called, card->ops->card_reader_lock_obtained will be called. If PCSC is being used as the reader driver, this occures just after pcsc_lock has done a SCardBeginTransaction and our process has exclusive control over the card. The card driver can then determine if the state of the card has changed, and take action to get the card into an acceptable state. If card->reader->ops->lock returns SC_ERROR_CARD_RESET, indicating some other process has interefered with the state of the card. was_reset=1 is passed to card->ops->card_reader_lock_obtained. Some examples of actions that could be done by the card driver is to select the AID and reset logged_in. Currently the card driver is not notified. So no default card_reader_lock_obtained is defined in iso7816.c Changes to be committed: modified: card.c modified: iso7816.c modified: opensc.h
When sc_lock obtains a reader lock this function is called If the card was reset the PIV AID is seletcted and logged_in is reset. This is need for some PIV cards where the default AID is not the PIV AID and some other process has reset the card. Changes to be committed: modified: card-piv.c
…penSC#842 This reverts commit e36036e.
|
@dengert this patch needs to be rebased against the current master. In its current state it doesn't even compile: The problem seems to stem from the fact that Same for P.S. I understand that it was written for #837, but #837 has been closed and will not be merged (a modification of it is now in the master as 1e82dbe). |
Yeah, I saw that...
By
Whatever was merged into my fork the from OpenSC/OpenSC master at the moment. I think so. But then, I just re-applied everything, and somehow it all compiled now. No explanation that I can see... Oh well... At least it builds. |
|
Reporting. #842 seems to work, as tested with NEO. The only case when it fails is this:
Here's the log: If I explicitly lock the token between steps (1) and (2), everything is fine. Update
P.S. Setting |
|
Rather then using the patch there is a way to use git pull of a PR, The github "graphs" "Network" can be very interesting, as you can see where I am on vacation now and don't have acess to me developemt environment of On Sun, Jul 31, 2016 at 6:13 AM, Mouse [email protected] wrote:
|
Yeah... I'm still mastering the art of rebasing, and of pulling PRs from other forks and repos. Though technically there shouldn't be any difference in the effect between pulling the PR through Git and downloading it as a patch and applying directly.
Haven't looked at that before. Will check it out, thanks.
Oh, no problem. I'm sure this isn't the first time the question surfaced on the 'Net, so somewhere (stackoverflow?) there bound to be an answer, probably more than one. Update. Found how to pull a PR from the upstream. Reasonably simple procedure. Enjoy your vacation! I'm looking forward to one, but probably not until the winter. :-( P.S. I wonder what's happening inside the OpenSC libopensc - when |
|
Warning shot over the bows: we may have a problem with CAC. I cannot comment more because it locked my CAC and I'll need to get it reset tomorrow. No problem with the NEO token. Update means there's no point asking the card for anything else, most of all to verify PIN? I've got 83 transactions I'll need to check, but am pretty sure tokend is not aware of that. |
|
Need a debug trace showing if verifies are failing and tries left are going On Mon, Aug 1, 2016 at 1:54 PM, Mouse [email protected] wrote:
|
I removed There's something fishy with how the whole thing behaves related to " = leave". When "leave" is set, it always prompts for the PIN when it's supposed to. But occasionally I get these problems. When "=leave" is not set, it rarely causes this kind of a problem, but exhibits one failure scenario as described in #842 (comment) . (You'd understand my reluctance to experiment with CAC too much, as getting it reset is not fun.)
Left at default, so I believe the answer is "turned on, cached for 10 attempts unless |
|
Will look at trace late next week. On Tue, Aug 2, 2016 at 2:15 PM, Mouse [email protected] wrote:
|
Great, thank you! It would be outstanding if you could look at/compare the traces with "=leave;" enabled and not enabled, and figure what's the difference - like, why in the latter case the code does not prompt for the PIN... |
|
Update Tried to connect to DCS via Web browser using CAC authentication. Several times the Web browser prompted me for my PIN, and appeared to be doing something with the token. But no successful connection appeared. Only the last attempt (24 minutes from the beginning) succeeded. Here's the log: |
Douglas E. Engert [email protected] |
Douglas E. Engert [email protected] |
I see your point, and cannot argue with your analysis of the provided logs. However, somehow if the |
Douglas E. Engert [email protected] |
Yes, I realize this. Which is why I'm trying to get this problem resolved, rather than resigning to the "=leave;" workaround.
Adding instrumentation to tokend is quite doable, as it is fully under my control - so I will do it (though I'd like some guidance as to what specific things to log - it seems that the current logging is reasonably extensive?). Adding debugging to pcscd should be possible - but I have neither control over the code, nor the knowledge. Adding debugging to Keychain seems impossible - and Apple does not help at all.
I think all of the above is happening within the OpenSC library, before the control flow passes to tokend. But I'll need to figure how to provide you an acceptable trace that contains everything you need to determine the place and cause of the problem. |
Douglas E. Engert [email protected] |
|
@viktorTarasov, @frankmorgner, @mouse07410 has been testing on MacOS, and as far as I can tell this PR is working as expected. His problems appear to be in the tokend and/or keychain, not in this PR. |
|
I think the Idea behind this PR is OK. Though I'd suggest to use the same logic as in
|
Douglas E. Engert [email protected] |
This is a replacement for #836. This new PR builds upon #837 and calls the card driver's card_reader_lock_obtained function whenever PCSC (or other reader driver) obtains the lock on the card.
This allows the card driver to take action at the start of a SCardBeginTransaction if needed.
A piv_card_reader_lock_obtained function is also added. If the card was reset, the PIV driver will select the AID again. There are some PIV cards where the PIV AID is not the default.