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

[Sean Mullan]

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
>>>>