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
