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

[Weijun Wang]

The last existing paragraph is already

    A system property named jdk.io.permissionsUseCanonicalPath has also 
been introduced. When it is set to "true", FilePermission will 
canonicalize its pathname as it did before JDK 9. The default value of 
this property is "false".

and I'd like the first sentence to be a little different.

--Max

On 02/15/2017 08:30 PM, Sean Mullan wrote:
> On 2/15/17 3:35 AM, Weijun Wang wrote:
>> 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".
>
> Looks fine. I suggest tweaking the wording a little:
>
> A system property named jdk.security.filePermCompat has also been
> introduced. When set to "true", the compatibility layer described above
> will also be supported for third-party Policy implementations. The
> default value of this property is "false".
>
> --Sean
>
>>
>> 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
>>>>>