RFR 8164705: Remove pathname canonicalization from FilePermission

[Weijun Wang]

Hi Alan

I am glad you think this change is useful.

As for the 3-value property, in my opinion even the absolute <=> 
relative translation might not be really useful in a production 
environment. Who can guarantee a program is always launched from a 
certain directory and access a file using a relative path? I secretly 
wish this never happens and a brave user would set the property to false 
so that there is no need for any compatibility code.

And yes, samepath.sh was from a very early stage of this change and I 
should rewrite it.

Thanks
Max

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
>>
>>    http://cr.openjdk.java.net/~weijun/8164705/webrev.00
>>
>> 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
>> involved.
>>
>> 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.
>
> -Alan