Bug ID: JDK-4202504 Should allow policy class to be provided as an extension or on CLASSPATH

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
1.4.0 beta2Fixed

We allow people to specify the class they want to use as the policy file:

# Class to instantiate as the system Policy. This is the name of the class
# that will be used as the Policy object.
#
policy.provider=sun.security.provider.PolicyFile

But in java.security.Policy we use Class.forName:

    policy = (Policy)Class.forName(policy_class).newInstance();

Which means the policy class must be on the bootclasspath. I'm
thinking we should change that to search the system class loader, so
the policy class can also exist in an extension or on the CLASSPATH.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin FIXED IN: merlin-beta2 INTEGRATED IN: merlin-beta2

14-06-2004

EVALUATION jan.luehe@Eng 1999-02-02 This is a catch 22 situation: Normally, you would use the application class loader to load the customized policy class. However, in order for the class to be loaded, the classloader needs to determine the permissions of its protection domain. In order to do that, it needs to consult the policy. This will be tricky to fix. gary.ellison@eng 2000-09-26 One possible solution is to modify java.security.Policy to attempt to instantiate the policy provider in a more robust fashion. For instance first attempt to instantiate the policy provider via Class.forName If that fails with a ClassNotFoundException then temporarily fall back on the default provider sun.security.provider.PolicyFile. Using this provider in a synchronized block attempt to load the desired provider through the SystemClassLoader. All classes dragged into the VM during this stage will get the permissions defined in the default java.policy file. If the provider successfully loads then install it as the policy provider. One minor variation on this theme is to the implement a bootstrap policy provider which simply grants AllPermission during this loading of configured policy provider (and dependent classes). The rationale for this is that the policy provider must be fully trusted anyway. A drawback is that we are putting policy in code which cannot be administered externally. One other point worth mentioning is that by fixing this bug we may be giving a false sense of flexibility. The policy provider could still have many dependencies on code which will not function unless it is on the bootclasspath. For example URL protocol handlers (see bugid 4297869). gary.ellison@eng 2001-07-27 a bootstrapping mechanism has been implemented .

27-07-2001

WORK AROUND jan.luehe@Eng 1999-02-02 Put customized policy class file on bootstrap classpath, i.e., include in rt.jar.

02-02-1999

Relates :	JDK-8075706 - Policy implementation does not allow policy.provider to be on the class path
Relates :	JDK-4714838 - Document that PolicyProviders must answer for its own ProtectionDomain