Page History

When a custom class loader must override the getPermissions() method, the implementation must consult the default system policy by explicitly invoking the superclass's getPermissions() method before assigning arbitrary permissions to the code source. A custom class loader that ignores the superclass's getPermissions() could load untrusted classes with elevated privileges. ClassLoader is abstract and must not be directly subclassed. 

Noncompliant Code Example

This noncompliant code example shows a fragment of a custom class loader that extends the class URLClassLoader. It overrides the getPermissions() method but does not call its superclass's more restrictive getPermissions() method. Consequently, a class defined using this custom class loader has permissions that are completely independent of those specified in the systemwide policy file. In effect, the class's permissions override them.

protected PermissionCollection getPermissions(CodeSource cs) {
  PermissionCollection pc = new Permissions();
  // allow exit from the VM anytime
  pc.add(new RuntimePermission("exitVM"));
  return pc;
}

...

In this compliant solution, the getPermissions() method calls super.getPermissions(). As a result, the default systemwide security policy is applied, in addition to the custom policy.

protected PermissionCollection getPermissions(CodeSource cs) {
  PermissionCollection pc = super.getPermissions(cs);
  // allow exit from the VM anytime
  pc.add(new RuntimePermission("exitVM"));
  return pc;
}

...

      14. Platform Security (SEC)      SEC08-J. Define wrappers around native methods