JDK-6379782 : Permissions effectively ignores latecomer UnresolvedPermissions
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 5.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2006-02-01
  • Updated: 2015-02-09
  • Resolved: 2015-02-09
Related Reports
Relates :  
Description
The Permissions class effectively ignores UnresolvedPermissions for a given class that are added after an actual instance of the class is added or passed to implies.  Demonstrated with this test program:

import java.security.*;

public class Test {

    public static class FooPermission extends BasicPermission {
	public FooPermission(String name) {
	    super(name);
	}
    }

    public static void main(String[] args) throws Exception {
	Permissions pc = new Permissions();
	pc.add(new FooPermission("foo"));
	pc.add(new UnresolvedPermission(FooPermission.class.getName(),
					"bar", null, null));
	if (!pc.implies(new FooPermission("bar"))) {
	    System.out.println("first test failed");
	}
	pc = new Permissions();
	pc.add(new UnresolvedPermission(FooPermission.class.getName(),
					"foo", null, null));
	if (!pc.implies(new FooPermission("foo"))) {
	    throw new RuntimeException("oops");
	}
	pc.add(new UnresolvedPermission(FooPermission.class.getName(),
					"bar", null, null));
	if (!pc.implies(new FooPermission("bar"))) {
	    System.out.println("second test failed");
	}
    }

}

Comments
"An unresolved permission is one whose actual Permission class does not yet exist at the time the Policy is initialized", the test program is an abuse of the class.
09-02-2015

EVALUATION The sample code in the bug report is an abuse of the UnresolvedPermission, which should be only used when the underlying permission class is truly *unresolved*. The current JDK implementation assumes this be true (for performance reasons), and ignores all newly added UnresolvedPermission of a Permission type {P} if {P} has already been resolved at a prior time. The "resolved" here can be that the Permission {P} itself is directly added (the first test), or it was added as unresolved but has been resolved in a previous permission check (the second test). However, we still believe this is a bug, and would like to find a way to fix it as a part of 6387002 Improve security check performance
18-04-2006

EVALUATION The problem here is that 2 FooPermission exist inside the Permissions object as resolved and unresolved at the same time. Either we have to accept (and play nicely with) this situation, or we need to make this disappear.
11-04-2006