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 via email to