RFR 8168410: Multiple JCK tests are failing due to SecurityException is not thrown.

[Weijun Wang]

I's also like to append the following paragraph to the current release 
note at https://bugs.openjdk.java.net/browse/JDK-8165836:

    Another new system property named jdk.security.filePermCompat, when 
set to "true", allows the compatibility layer above to work on 
third-party Policy implementations as well. The default value of this 
property is "false".

Thanks
Max


On 02/15/2017 09:04 AM, Weijun Wang wrote:
> Webrev updated at
>
>    http://cr.openjdk.java.net/~weijun/8168410/webrev.01/
>
> Change since webrev.00:
>
>   http://cr.openjdk.java.net/~weijun/8168410/webrev.01/interdiff.patch.html
>
> Thanks
> Max
>
> On 02/14/2017 11:55 PM, Sean Mullan wrote:
>> Hi Max,
>>
>> I agree this change is necessary so that we can resolve this tck-red
>> issue before ZBB. However, since the TCK Policy provider implementation
>> is not a "typical" implementation in the sense that it is denying
>> permissions instead of granting permissions, I think we should continue
>> to explore if there are any better options post-ZBB.
>>
>> A few minor comments:
>>
>> * ProtectionDomain.java
>>
>> Can you add more comments describing the purpose of the new property
>> before lines 66 and 340?
>>
>> * CompatImpact.java
>>
>> Shouldn't you add 8168410 to the @bug line?
>>
>> --Sean
>>
>> On 2/13/17 9:53 PM, Weijun Wang wrote:
>>> Please take a review at
>>>
>>>     cr.openjdk.java.net/~weijun/8168410/webrev.00
>>>
>>> JDK-8164705 introduced a compatibility layer to make sure that when
>>> FilePermission on "/pwd/x" is granted you can still read "x". The
>>> compatibility layer has 2 parts:
>>>
>>> 1. Inside our own default policy provider.
>>>
>>> 2. Inside ProtectionDomain.
>>>
>>> Multiple JCK tests fail because of #2. After some discussion, we decide
>>> to only enable #2 when a new system property jdk.security.filePermCompat
>>> is set.
>>>
>>> This means if user is using a customized policy implementation, the
>>> compatibility layer will not work, and granting a FilePermission on "x"
>>> will not allow the code reading "/pwd/x" when a security manager is on.
>>>
>>> Hopefully this is acceptable because:
>>>
>>> 1. A customized policy implementation is seldom used.
>>>
>>> 2. After JDK-8164705, we advise users to update their policy file so
>>> that the FilePermission path matches how a file is actually accessed. So
>>> if an application is reading "/pwd/x", the permission on "/pwd/x"
>>> (instead if "x") should be granted.
>>>
>>> Thanks
>>> Max
>>>