> On 1 Feb 2017, at 22:19, Vladimir Kozlov wrote:
>
> AOT tool jaotc does not run with SecurityManager. We assume it runs in secure
> environment and it does not access any external resources.
Great.
Can I now consider this change reviewed and integrate it?
-Doug
> On 1 Feb 2017, at 20:54, Sean Mullan wrote:
>
> Couple of comments:
>
> - jdk.vm.ci is already loaded by the boot loader so it is implicitly granted
> AllPermission and does not need an entry in default.policy.
Thanks - I removed it.
> - all internal APIs in the
On 02/02/2017 02:12, Mandy Chung wrote:
On Feb 1, 2017, at 3:07 AM, Doug Simon wrote:
I’ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable
platform module, this allowing it to be mentioned in default.policy:
> On Feb 1, 2017, at 3:07 AM, Doug Simon wrote:
>
> I’ve reworked the webrev as requested to make jdk.vm.compiler a
> non-upgradeable platform module, this allowing it to be mentioned in
> default.policy:
>
> http://cr.openjdk.java.net/~dnsimon/8145337/
Looks good.
On 2/1/17 4:27 PM, Doug Simon wrote:
Can I now consider this change reviewed and integrate it?
Yes.
--Sean
AOT tool jaotc does not run with SecurityManager. We assume it runs in secure
environment and it does not access any external resources.
Thanks
Vladimir
> On Feb 1, 2017, at 12:03 PM, Doug Simon wrote:
>
>
>> On 1 Feb 2017, at 20:54, Sean Mullan
Couple of comments:
- jdk.vm.ci is already loaded by the boot loader so it is implicitly
granted AllPermission and does not need an entry in default.policy.
- all internal APIs in the jdk.vm.compiler module will now be restricted
by default by SecurityManager::checkPackageAccess(), so if you
> On 30 Jan 2017, at 21:55, Mandy Chung wrote:
>
>
>> On Jan 30, 2017, at 10:38 AM, Doug Simon wrote:
>>
>> I’ve extended the webrev with that change - please re-review:
>>
>> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev
>>
>
> +1
I’ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable
platform module, this allowing it to be mentioned in default.policy:
http://cr.openjdk.java.net/~dnsimon/8145337/
-Doug
> On 30 Jan 2017, at 22:53, Mandy Chung wrote:
>
>>
>> On Jan 30,
> On Jan 30, 2017, at 1:36 PM, Doug Simon wrote:
>
>
>> On 30 Jan 2017, at 21:55, Mandy Chung wrote:
>>
>>
>>> On Jan 30, 2017, at 10:38 AM, Doug Simon wrote:
>>>
>>> I’ve extended the webrev with that change - please
> On 30 Jan 2017, at 17:11, Mandy Chung wrote:
>
> Moving it to platform class loader is okay with me. I’m still unsure if
> jdk.vm.compiler should be defined by the boot loader instead and you may want
> to look into in a future release.
We also want jdk.vm.compiler
> On 29 Jan 2017, at 20:34, Igor Veresov wrote:
>
>>
>> On Jan 27, 2017, at 3:40 PM, Christian Thalinger
>> wrote:
>>
>>>
>>> On Jan 26, 2017, at 7:40 AM, Doug Simon wrote:
>>>
On 26 Jan 2017, at 17:55,
> On Jan 26, 2017, at 7:40 AM, Doug Simon wrote:
>
>>
>> On 26 Jan 2017, at 17:55, Mandy Chung wrote:
>>
>>
>>> On Jan 26, 2017, at 3:13 AM, Doug Simon wrote:
>>>
jdk.vm.compiler is defined by the application
> On Jan 30, 2017, at 10:38 AM, Doug Simon wrote:
>
> I’ve extended the webrev with that change - please re-review:
>
> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev
>
+1
> Strangely, there was no existing declaration of jdk.vm.compiler in
> Modules.gmk.
>
> On 26 Jan 2017, at 17:55, Mandy Chung wrote:
>
>
>> On Jan 26, 2017, at 3:13 AM, Doug Simon wrote:
>>
>>>
>>> jdk.vm.compiler is defined by the application class loader and it’s used by
>>> AOT tool. I wonder why it has to run with security
> On 26 Jan 2017, at 03:32, Mandy Chung wrote:
>
> (dropping jdk9-dev. security-libs is the appropriate list to review security
> permission)
>
>> On Jan 23, 2017, at 1:56 PM, Doug Simon wrote:
>>
>> Both jdk.vm.ci and jdk.vm.compiler require
> On Jan 26, 2017, at 3:13 AM, Doug Simon wrote:
>
>>
>> jdk.vm.compiler is defined by the application class loader and it’s used by
>> AOT tool. I wonder why it has to run with security manager.
>
> Without java.security.AllPermission, the policy for jdk.vm.compiler
(dropping jdk9-dev. security-libs is the appropriate list to review security
permission)
> On Jan 23, 2017, at 1:56 PM, Doug Simon wrote:
>
> Both jdk.vm.ci and jdk.vm.compiler require a number of permissions when a
> security manager is present. Since neither of these
Both jdk.vm.ci and jdk.vm.compiler require a number of permissions when a
security manager is present. Since neither of these modules is accessible to
application code, it should be ok to give them all permissions. This seems to
be the approach for a number of other modules including
19 matches
Mail list logo