RFR 8164705: Remove pathname canonicalization from FilePermission
weijun.wang at oracle.com
Thu Sep 1 14:25:40 UTC 2016
Webrev updated at
Most suggestions from Alan accepted, including:
1. Using SharedSecrets.getJavaIOFilePermissionAccess() style instead of
3. samepath.sh rewritten in ReadFileOnPath.java.
Still using "ugly" method names. Thinking they are clear enough.
On 8/29/2016 20:18, Alan Bateman wrote:
> On 25/08/2016 04:55, Weijun Wang wrote:
>> Hi All
>> Please take a look at
>> From the beginning of JDK, FilePermission canonicalizes the input path
>> and use the result in implies() and equals(). This has been a big
>> performance hurt and leads to confusing results when symlinks are
>> The code change above removes the canonicalization.
>> This means FilePermission on "/the/current/working/directory/x" no
>> longer implies that on "x". Since this might bring quite some
>> compatibility risk, the code change includes some tweaks in permission
>> checking to make sure an app is still able to read "x" when the
>> FilePermission granted is on "/the/current/working/directory/x".
>> However, we still hope the policy to be updated to be consistent of
>> how a file is actually accessed.
>> No tweak is devoted to make granting "/this/is/a/symlink" to imply
>> reading of "/the/actual/target/file", because we think it should not.
>> This is quite a big behavior change. If it breaks your app/lib, or
>> does not work with your customized security manager or policy
>> implementation, please let us know.
>> Feel free to provide any feedback.
>> Finally, a new system property "jdk.filepermission.canonicalize" is
>> introduced and it can be "true", "false", or "compat". The out-of-box
>> default is "compat", which means no canonicalization with check tweaks.
> I've taken a first pass over this. A general comment then it's great to
> see FilePermission changed to not do canonicalization. The "new
> behavior" approach to match paths and support absolute => relative and
> relative => absolute all makes sense.
> I agree that having a property to revert to legacy behavior make sense.
> Is there any way to reduce this down to just current and legacy
> behavior, it's otherwise too complicated to describe the subtle
> differences between "false" and "compat". If it can be reduced to two
> settings then a name such as
> jdk.io.permissionsUseCanonicalPath=<boolean> could be better than the
> prototype name.
> For the implementation then I think it will cleanup before this is ready
> to push. FilePermCompat is a ugly, particularly FilePermission changing
> its public fields. Also method names like impliesWithAltFP,
> newPermPlusAltPath, ... could be re-visited to make them much clearer.
> For the test then it would be good if samepath.sh could be replaced with
> a non-shell test.
More information about the core-libs-dev