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
