[14] RFR(M) 8185139: [Graal] Tests which set too restrictive security manager fail with Graal
Mandy Chung
mandy.chung at oracle.com
Thu Jun 20 06:23:06 UTC 2019
Hi Vladimir,
Indeed these are test issues that the tests will need to grant permissions
to jdk.internal.vm.compiler as the default policy grants.
Thanks for going extra miles to fix the tests.
My suggestion may be a bit general. What I intend to say the custom
security policy should extend the default policy unless it intentionally
excludes configuring permissions for specific modules. I review the
the patch but the test doesn't clearly tell what the test intends to
do w.r.t. security configuration.
We should avoid inadvertently granting permissions that the test expects
to disallow. A better solution is to limit granting permissions just for
`jdk.internal.vm.compiler` module rather than all.
Attached is ModulePolicy class that allows you to get the Policy for
a specific module. It can be put in the test library that these tests
can use them.
So the test can call ModulePolicy.get("jdk.internal.vm.compiler") and
implies method will call the returned ModulePolicy if present.
test/lib/jdk/test/lib/security is one existing testlibrary for security
related stuff. You can consider putting ModulePolicy.java there.
This is one idea.
Mandy
On 6/19/19 6:03 PM, Vladimir Kozlov wrote:
> http://cr.openjdk.java.net/~kvn/8185139/webrev.00/
>
> https://bugs.openjdk.java.net/browse/JDK-8185139
>
> For Graal to work we have to give Graal module all permissions which
> is specified in default policy [1].
> Unfortunately this cause problem for Graal running tests which
> overwrite default policy.
>
> I discussed this with Mandy and she suggested that such tests should
> also check default policy. I implemented her suggestion. Note, this is
> not only Graal problem. There were already similar fixes before [2].
>
> I also updated Graal's problem list. Several tests were left on
> problem list (with different bug id) because they would not run with
> Java Graal (for example, they use --limit-modules flag which prevents
> loading Graal module). We will enable such tests again when libgraal
> is supported.
>
> I ran testing which execute these tests with Graal. It shows only
> known problems which are not related to these changes.
>
> Thanks,
> Vladimir
>
> [1]
> http://hg.openjdk.java.net/jdk/jdk/file/49ed5e31fe1e/src/java.base/share/lib/security/default.policy#l156
> [2] https://bugs.openjdk.java.net/browse/JDK-8189291
-------------- next part --------------
import java.lang.module.*;
import java.net.*;
import java.util.HashMap;
import java.util.Map;
import java.util.Optional;
import java.util.function.Function;
import java.util.stream.*;
import java.security.*;
public class ModulePolicy extends Policy {
private static final Policy DEFAULT_POLICY = Policy.getPolicy();
private static final Map<String, ModulePolicy> modulePolicies =
ModuleLayer.boot()
.configuration().modules().stream()
.map(rm -> new ModulePolicy(rm))
.collect(Collectors.toMap(ModulePolicy::name, Function.identity()));
public static Optional<ModulePolicy> get(String name) {
return Optional.ofNullable(modulePolicies.get(name));
}
final String name;
final URL codeSourceUrl;
final PermissionCollection permissions;
private ModulePolicy(ResolvedModule rm) {
URL url = createURL(rm.reference().location().orElseThrow());
CodeSource cs = new CodeSource(url, (CodeSigner[]) null);
this.name = rm.name();
this.codeSourceUrl = url;
this.permissions = DEFAULT_POLICY.getPermissions(cs);
}
public String name() {
return name;
}
private URL createURL(URI uri) {
URL url = null;
try {
url = uri.toURL();
} catch (MalformedURLException | IllegalArgumentException e) {
}
return url;
}
@Override
public PermissionCollection getPermissions(CodeSource cs) {
return codeSourceUrl.equals(cs.getLocation()) ? permissions : new Permissions();
}
@Override
public boolean implies(ProtectionDomain domain, Permission perm) {
return permissions.implies(perm);
}
}
More information about the security-dev
mailing list