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
>