<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFCC">
Hi,<br>
<br>
If this were java.base, we would use doPrivilege to ignore the
policy and place specific limits.<br>
Encumbering the default policy with conditions needed by a trusted
subsystem seems<br>
like distributing what should be a local implementation issue.<br>
<br>
$.02, Roger<br>
<br>
<div class="moz-cite-prefix">On 6/20/19 2:23 AM, Mandy Chung wrote:<br>
</div>
<blockquote type="cite"
cite="mid:89d31dd3-6eeb-6727-b2db-59ee2e572b7b@oracle.com">Hi
Vladimir,
<br>
<br>
Indeed these are test issues that the tests will need to grant
permissions
<br>
to jdk.internal.vm.compiler as the default policy grants.
<br>
<br>
Thanks for going extra miles to fix the tests.
<br>
<br>
My suggestion may be a bit general. What I intend to say the
custom
<br>
security policy should extend the default policy unless it
intentionally
<br>
excludes configuring permissions for specific modules. I review
the
<br>
the patch but the test doesn't clearly tell what the test intends
to
<br>
do w.r.t. security configuration.
<br>
<br>
We should avoid inadvertently granting permissions that the test
expects
<br>
to disallow. A better solution is to limit granting permissions
just for
<br>
`jdk.internal.vm.compiler` module rather than all.
<br>
<br>
Attached is ModulePolicy class that allows you to get the Policy
for
<br>
a specific module. It can be put in the test library that these
tests
<br>
can use them.
<br>
<br>
So the test can call ModulePolicy.get("jdk.internal.vm.compiler")
and
<br>
implies method will call the returned ModulePolicy if present.
<br>
<br>
test/lib/jdk/test/lib/security is one existing testlibrary for
security
<br>
related stuff. You can consider putting ModulePolicy.java there.
<br>
<br>
This is one idea.
<br>
<br>
Mandy
<br>
<br>
On 6/19/19 6:03 PM, Vladimir Kozlov wrote:
<br>
<blockquote type="cite"><a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~kvn/8185139/webrev.00/">http://cr.openjdk.java.net/~kvn/8185139/webrev.00/</a>
<br>
<br>
<a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8185139">https://bugs.openjdk.java.net/browse/JDK-8185139</a>
<br>
<br>
For Graal to work we have to give Graal module all permissions
which is specified in default policy [1].
<br>
Unfortunately this cause problem for Graal running tests which
overwrite default policy.
<br>
<br>
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].
<br>
<br>
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.
<br>
<br>
I ran testing which execute these tests with Graal. It shows
only known problems which are not related to these changes.
<br>
<br>
Thanks,
<br>
Vladimir
<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="http://hg.openjdk.java.net/jdk/jdk/file/49ed5e31fe1e/src/java.base/share/lib/security/default.policy#l156">http://hg.openjdk.java.net/jdk/jdk/file/49ed5e31fe1e/src/java.base/share/lib/security/default.policy#l156</a><br>
[2] <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8189291">https://bugs.openjdk.java.net/browse/JDK-8189291</a>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>