Konstantin,
On 4/20/16 8:31 AM, Konstantin Kolinko wrote:
> 2016-04-19 22:42 GMT+03:00 Mark Thomas <ma...@apache.org>:
>> On 19/04/2016 19:38, Dimitar Valov wrote:
>>> All static resources such as index.html will not be found when application
>>> is added with <Context path="/" docBase="../../../"/>, for example tomcat
>>> is put inside the application's META-INF.
>>>
>>> I've drilled down that the AbstractFileResourceSet class is responsible for
>>> this behaviour, inside the protected final File file(String name, boolean
>>> mustExist) method. There absoluteBase and canonicalBase (absolute, unique
>>> with resolved symlinks) are used to determine if the file should be
>>> accessed based on a case sensitivity check.
>>>
>>> Everything works fine if the docBase is not just path like ../../.././../
>>> but has an actual directory at the end, like ../../../web-app. However in
>>> this edgy case the difference appears since the behaviour of
>>> the org.apache.tomcat.util.http.RequestUtil.normalize method has slightly
>>> different behavior than the File.getCanonicalPath.
>>>
>>> System.out.println(RequestUtil.normalize("/base/1/2/3/../../../"));
>>> /base/
>>>
>>> System.out.println(RequestUtil.normalize("/base/1/2/3/../../.."));
>>> /base/1/..
>>> System.out.println(new File("/base/1/2/3/../../../").getCanonicalPath());
>>> /base
>>>
>>> The added /from RequestUtil breakes the logic inside the file method, since
>>> when doing the substring operation inside AbstractFileResourceSet.file
>>> method it may or may not have a trailing /. In such situation <whatever
>>> path>/index.html substring with the absoluteBase becomes ndex.html. At the
>>> end the file method returns from here:
>>>
>>> if (!canPath.equals(absPath)) // !"index.html".equals("ndex.html")
>>> => true
>>> return null;
>>>
>>> The RequestUtil comes from the http packages and follows their conventions
>>> when normalizing the path, so an obvious way to fix this is to add and if
>>> statement after the normalization
>>> inside AbstractFileResourceSet.initInternal.
>>>
>>> this.absoluteBase = normalize(absolutePath);
>>> if (this.absoluteBase.endsWith("/")) {
>>> this.absoluteBase = this.absoluteBase.substring(0,
>>> this.absoluteBase.length() - 1);
>>> }
>>>
>>> With Java 7 instead of using the RequestUtil for normalization, Path
>>> java.nio.file.Path.normalize() can accomplish the correct thing.
>>>
>>> Do you think that is something that can be fixed? Maybe the above is not
>>> the best approach, however it's the least invasive.
>>
>> We need to be very careful here since this is security sensitive.
>>
>> Given that normalize handles URIs, there is an argument for slightly
>> different handling of trailing '/'. I'm currently of the view (subject
>> to the results of some local tests I am running) that if the input ends
>> in '/', so should the output. If the input doesn't end in '/' neither
>> should the output unless the output is the string "/".
>>
>> The end result is likely to be that docBase values should not end in "/".
>>
>
> (I have not looked at the context. Just a general comment / review of
> r1740134)
>
> There is a risk of normalizing Windows path of "C:\foo\.." into "C:"
> which denotes the current directory on drive C: while the expected
> value is the root of the drive, "C:\".
>
> I have not tested how java.io.File("C:") actually works.
I don't have a Windows machine handy right this minute, but from my
previous experience, "C:" means "the current working directory on the C
drive, from this process's perspective.
For instance:
D:\> DIR C:\
...
Program Files
Windows
...
D:\> DIR C:
...
Program Files
Windows
...
D:\> CD C:\Windows
D:\> DIR C:
...
System
System32
...
So I would think that using "C:" (with no trailing path) from Java would
behave the same way: the current working directory *on that drive* would
be the one used.
I would expect it to work just like "." on *NIX.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
