Preempted Access Control Checking result in undesired API behavior

[GoogleCodeExporter]

When the access control applet is not multi-selectable (which is the case on 
most Vendor’s implementation), access control checking mechanism can be 
preempted and cause undesired behavior.  Think of multiple clients or multiple 
threads trying to use openLogicalChannel against their respected AIDs at the 
same time, but during access control checking on the first thread, it is being 
preempted.  The 2nd thread would get a Security Exception, because they would 
be getting error when AC applet is already selected (and not release yet) and 
cannot be select a 2nd time.  This is a wrong behavior, because the checking of 
access control is transparent to SEEK user and Security Exception should only 
be thrown if access is denied (not because of limitation on cannot be 
multi-selecting the applet).

There’re 2 possible solutions for this:
1)  Support multi-selectable on Access Control Applet, which is not currently a 
mandated requirement, and there’re some complication to handle OTA rule 
update correctly when someone is querying the data at the same time
2)  Or, make the enforcer access control rule checking be thread safe.

While 1st approach might be the ultimate solution if implemented properly, 2nd 
approach is something that can be implemented by SEEK, based on the current 
known limitation on applet, without any dependency.
Simply by making sure the Access Control checking, from the time it open the AC 
applet until closes the channel to it is locked by a critical section.  It can 
be done by adding the “synchronized” keyword to the following function 
signature:

In src/org/simalliance/openmobileapi/service/security/AccessController.java

public ChannelAccess enableAccesssConditions(ITerminal terminal, byte[] aid, 
String callerPakcageName, ISmartcardServiceCallback callback, SmartcardError 
error) throws Exception

become

public <b>synchronized</b> ChannelAccess enableAccesssConditions(ITerminal 
terminal, byte[] aid, String callerPakcageName, ISmartcardServiceCallback 
callback, SmartcardError error) throws Exception

Original issue reported on code.google.com by tommypo...@gmail.com on 18 Feb 2013 at 6:59

[GoogleCodeExporter]

Approach #2 in SCPAI-3.0.0

Original comment by Daniel.A...@gi-de.com on 15 Apr 2013 at 3:40

• Changed state: Fixed

[GoogleCodeExporter]

setting old issues from fixed to done

Original comment by Daniel.A...@gi-de.com on 5 Jul 2013 at 2:33

• Changed state: Done