[14] RFR(M) 8185139: [Graal] Tests which set too restrictive security manager fail with Graal
Roger Riggs
Roger.Riggs at oracle.com
Thu Jun 20 13:32:35 UTC 2019
Hi,
If this were java.base, we would use doPrivilege to ignore the policy
and place specific limits.
Encumbering the default policy with conditions needed by a trusted
subsystem seems
like distributing what should be a local implementation issue.
$.02, Roger
On 6/20/19 2:23 AM, Mandy Chung wrote:
> 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 --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20190620/611b3743/attachment.htm>
More information about the security-dev
mailing list