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
