Quantcast

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

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Sean Mullan
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
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Weijun Wang
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
>>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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
>>>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Sean Mullan
In reply to this post by Weijun Wang
Looks good.

--Sean

On 2/14/17 8:04 PM, 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
>>>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Sean Mullan
In reply to this post by Weijun Wang
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
>>>>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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
>>>>>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Weijun Wang
In reply to this post by Sean Mullan


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.

Some JAXP tests fail [1] after this code change, and I believe the case
there -- permission on ${user.dir}/- granted, access base name without
directory -- is the most popular one we want to support. But I cannot
think of any solution that could make the TCK tests pass.

--Max

[1] https://bugs.openjdk.java.net/browse/JDK-8175043
Loading...