RFR: 8159752: Grant de-privileged module permissions by default with java.security.policy override option

[Chris Hegarty]

> On 14 Jul 2016, at 21:05, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> Please review this change to the default Policy provider implementation to grant de-privileged module permissions by default even when the java.security.policy override option is specified or when the Policy.getInstance API is used:
> 
> http://cr.openjdk.java.net/~mullan/webrevs/8159752/webrev.00/ <http://cr.openjdk.java.net/~mullan/webrevs/8159752/webrev.00/>

This makes sense. A quick skim shows nothing untoward.

> A new system-wide policy file located in ${java.home}/lib/security/default.policy has been created. It contains grant statements containing the permissions that need to be granted to de-privileged modules. These grant statements were previously located in the ${java.home}/conf/security/java.policy file and have been relocated to the default.policy file.
> 
> The default.policy file is now always loaded by the default Policy provider implementation (sun/security/provider/PolicyFile). It is loaded if the java.security.policy '=' or '==' option is specified, and also if the application uses the Policy.getInstance methods and specifies the "JavaPolicy" type. If the default.policy file cannot be loaded, an InternalError is thrown, on the basis that the runtime cannot operate correctly unless these permissions are granted.

I think this is ok, but of course it is unnecessary for a minimal image with just java.base. Probably not worth complicating things, but you could conditionally add include the permissions per module based on its presence.

> The rationale for making this change is that the runtime should be responsible for granting the permissions it needs to operate correctly. We should not expect users to have to determine or copy and paste these permissions into their own policy files.

Sounds reasonable.

-Chris.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20160714/69f10fe8/attachment.htm>