WebStart, custom security policy and debugging

Question

Hi,
Please forgive the long post, it's an obscure problem.
A year ago I implemented a custom instance-centric security policy that uses a database for storing permission data. It has served our needs very well on the server side. Now, however, I need to reuse it in a client application deployed to about 50 users via WebStart (there are more similar applications coming which will take the user base to about 200).
For some reason, the permissions are not being properly evaluated under WebStart. Tracing through my policy code, I can see that calls to imply() return with expected true/false values, however, when the internals of Java's underlying security API aggregate the results, calls to AccessController.checkPermission() don't raise exceptions when and where they are expected to.
This is really a hard problem to debug/trace. When I run the application locally, I have no problems with security checks even if I run it under a security manager (via -D.java.security.manager). Tracing to standard helps to a point and I can see that there is a difference: during the local runs, calls to MyCustomPolicy.implies(Permission, Domain) are made once per every AccessController.checkPermission() call made from the business layer. Under WebStart, there are three calls to MyCustomPolicy.implies() per every call to AccessController.checkPermission(). All three calls seem to come from the same stack frame. All three return 'false', yet AccessController.checkPermission() doesn't raise an exception.
Analyzing stack's state at the point MyCustomPolicy.implies() is been called, I think the answer to my problem may lie in the following code snippet of AccessControlContext.checkPermission(Permission):
        for (int i=0; i< context.length; i++) {
            if (context[i] != null &&  !context.implies(perm)) {
if (debug != null) {
debug.println("access denied "+perm);
if (Debug.isOn("failure")) {
Thread.currentThread().dumpStack();
final ProtectionDomain pd = context[i];
final Debug db = debug;
AccessController.doPrivileged (new PrivilegedAction() {
public Object run() {
db.println("domain that failed "+pd);
return null;
throw new AccessControlException("access denied "+perm, perm);
I believe that somehow one of the iterations gets to "return null" line, but at the moment I have no way of verifying this.
I'm finally getting to my question. In order for me to understand what's going on, I need to enable debugging of AccessControlContext. I can do this by setting java.security.debug system property. Again, I have no problem enabling debugging on a local system, but not under WebStart.
Here's what the relevant markup in the .jnlp file looks like:
<resources>
<j2se version="1.5" max-heap-size="128m" initial-heap-size="32m" java-vm-args="-Djava.security.debug=all">
</j2se>
<!-- a bunch of jar declarations -->
<property name="java.security.auth.login.config" value="jar:swing-app-SNAPSHOT.jar!/jaas_login.properties">
</property>
<property name="java.security.debug" value="all">
</property>
</resources>
this seems to have no effect and no debugging output appears. Any ideas why? Is there anything else I can do to enable debugging of AccessControlContext under WebStart?
I don't expect too many replies to my post (unless 3 sleepless weeks made me miss something really obvious), but if anyone can offer a hit/hit/insightful comment :), that would be great.
Dmitry

Answer 1

Hey
I have just finished such a policy implemention - boy could I have done with your help!
I've never seen the java.security.debug property before - not to say it doesn't exist, but don't confuse system properties and security properties. Try setting it programmatically via Security.setProperty() or the Java Admin console [if you can], or even in the JRE WebStart uses via the java.security file.
When you run it locally with security switched on, do you observe the 3-to-1 behaviour also? I'm not sure if this is important - depends on your answer. As for the checks being performed from the same stack frame, the AC iterates over the protection domains as it checks them; the 3-to-1 behaviour is the result of there being 3 extra frames to check, possibly due to the fact your executing from JWS [although I'd expect JWS to be considered system code]. If the execution in AC gets to return null; then Debug.isOn("failure") must evaluate to true [...I'd slump in my chair at this point] but there's no way to figure out accurately what the semantics of this is AS THERE'S NO FRICKIN SRC AVAILABLE [...this really annoys me]. The only thing I can suggest for that is to not try and switch debugging on.
I suspect you are using JAAS [hence the dynamic policy need]? I have an idea if you are.
I totally know what you mean about the sleepless nights mate - I'm glad I done it all now, learnt all about security within Java which I knew nothing about 6 months ago.
Warm regads,
D