Review request: 8040059 Change default policy for extensions to no permission

Mandy Chung mandy.chung at
Thu Apr 24 23:07:30 UTC 2014

Thanks Sean.

I have updated the webrev:

Erik - I'm including build-dev to review the build change for 
java.policy file.


On 4/24/14 11:32 AM, Sean Mullan wrote:
> On 04/23/2014 05:29 PM, Mandy Chung wrote:
>> On 4/23/2014 1:10 PM, Sean Mullan wrote:
>>> Just a few comments:
>>> 1. When you write a test that uses the jtreg /policy option, the
>>> policy file overrides the system policy file. If the test depends on a
>>> standard extension, then you may get SecurityExceptions unless
>>> additional perms are granted. Thus, there are quite a few tests that
>>> define their own policy files and duplicate the grant statement for
>>> extensions from the system policy:
>>>     grant codeBase "file:${{java.ext.dirs}}/*" {
>>>         permission;
>>>     }
>>> These tests should be modified to only grant the necessary
>>> permissions. However, ideally I think that a better solution would be
>>> to add a jtreg /policy option that doesn't override the system policy
>>> file, but rather appends to it, for example, using "==" :
>> I suspect most of the tests only want to grant the permissions for the
>> test itself rather than overriding the system policy file. Having a new
>> jtreg/policy option not to override the system policy file may be a
>> better solution.    This would avoid updating the test's policy file
>> every time the system's policy is modified.   On the other hand, I think
>> the test policy may not need to grant permissions to the extensions
>> directory if it doesn't use the classes in extensions.  It's a good
>> opportunity to clean that up. This will require some closer look at the
>> tests.
>> If you are okay, I'd like to separate the test's custom policy update as
>> a follow-on work.
> That's fine with me.
>>> @run main/othervm/policy==test.policy
>>> (this is the reverse behavior of the system
>>> property, so it might be a little confusing, so maybe it is better to
>>> add a new option)
>> "==" is a confusing syntax.
>> overrides the system policy file ("=" prefix) whereas jtreg uses the
>> reverse syntax? I think it would be better to make jtreg/policy
>> consistent with (i.e. default is to extend the
>> system
> Would be nice, but not sure if we can change it at this point. Anyway, 
> one of us should file a jtreg RFE.
>>> 3. jdk/nio/zipfs/
>>> If I understand the changes, the previous code would throw
>>> SecurityExceptions when run under a SecurityManager? It's not
>>> specifically related to this bug, is it?
>> It's a bug in the zipfs provider and I can file a new JBS issue for the
>> zipfs change.  I prefer to push them in the same changeset that reduces
>> zipfs's privileges and added tests to run with security manager.
> Sure, it is fine with me to include them with this. I just wanted to 
> make sure I understood the changes.
> --Sean

More information about the security-dev mailing list