Re: context root with relative path

[David kerber]

On 5/9/2016 11:34 AM, Dimitar Valov wrote:

Hi,

Have you decided if the proposed fix make since? If the corner case is
:/, then it can be handled as well, not to remove the slash in case
the previous char is :.


IMO, the correct result for this case would most likely be to INCLUDE 
the trailing "/" if the previous character is a ":".  Generally you are 
going to want to end up with "the root of ", not "the default 
directory on ".






Best Regards,
Dimitar

On Thu, Apr 21, 2016 at 7:12 PM, Leo Donahue  wrote:


On Apr 21, 2016 10:38 AM, "David kerber"  wrote:


On 4/21/2016 11:33 AM, Leo Donahue wrote:


Chris,

On Apr 21, 2016 9:15 AM, "Christopher Schultz" <

ch...@christopherschultz.net>

wrote:



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

--



On Windows 7 from a command prompt:


C:\downloads dir c:


Shows contents of downloads


C:\downloads dir c:\


Shows contents of c drive



Yes, that's all well-known on windows.  The question was, how does the

Java File object handle it?   Does it give the correct result as above?
And going back to the original question, how should these paths be
normalized?

Let's hope this looks right, pasting code from Android device...

*import* java.io.File;

*import* java.net.URI;

*import* java.net.URISyntaxException;

*import* java.util.ArrayList;

*import* java.util.List;



*public* *class* Demo

{

*public* *static* *void* main(String[] args)

{

List paths = *new* ArrayList(2);

paths.add("file:/c:");

paths.add("file:/c:/");



*for* (String x : paths)

{

*try*

{

URI uri = *new* URI(x);

File f = *new* File(uri);

System.*out*.println(f.getAbsolutePath());

}

*catch* (URISyntaxException e)

{

e.printStackTrace();

}

   }

}

}






-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: context root with relative path

[Dimitar Valov]

Hi,

Have you decided if the proposed fix make since? If the corner case is
:/, then it can be handled as well, not to remove the slash in case
the previous char is :.

Best Regards,
Dimitar

On Thu, Apr 21, 2016 at 7:12 PM, Leo Donahue  wrote:

> On Apr 21, 2016 10:38 AM, "David kerber"  wrote:
> >
> > On 4/21/2016 11:33 AM, Leo Donahue wrote:
> >>
> >> Chris,
> >>
> >> On Apr 21, 2016 9:15 AM, "Christopher Schultz" <
> ch...@christopherschultz.net>
> >> wrote:
> >>>
> >>>
> >>> 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
> >>>
> >>> --
> >>
> >>
> >> On Windows 7 from a command prompt:
> >>
> >>> C:\downloads dir c:
> >>
> >> Shows contents of downloads
> >>
> >>> C:\downloads dir c:\
> >>
> >> Shows contents of c drive
> >
> >
> > Yes, that's all well-known on windows.  The question was, how does the
> Java File object handle it?   Does it give the correct result as above?
> And going back to the original question, how should these paths be
> normalized?
>
> Let's hope this looks right, pasting code from Android device...
>
> *import* java.io.File;
>
> *import* java.net.URI;
>
> *import* java.net.URISyntaxException;
>
> *import* java.util.ArrayList;
>
> *import* java.util.List;
>
>
>
> *public* *class* Demo
>
> {
>
> *public* *static* *void* main(String[] args)
>
> {
>
> List paths = *new* ArrayList(2);
>
> paths.add("file:/c:");
>
> paths.add("file:/c:/");
>
>
>
> *for* (String x : paths)
>
> {
>
> *try*
>
> {
>
> URI uri = *new* URI(x);
>
> File f = *new* File(uri);
>
> System.*out*.println(f.getAbsolutePath());
>
> }
>
> *catch* (URISyntaxException e)
>
> {
>
> e.printStackTrace();
>
> }
>
>}
>
> }
>
> }
>

Re: context root with relative path

[Leo Donahue]

On Apr 21, 2016 10:38 AM, "David kerber"  wrote:
>
> On 4/21/2016 11:33 AM, Leo Donahue wrote:
>>
>> Chris,
>>
>> On Apr 21, 2016 9:15 AM, "Christopher Schultz" <
ch...@christopherschultz.net>
>> wrote:
>>>
>>>
>>> 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
>>>
>>> --
>>
>>
>> On Windows 7 from a command prompt:
>>
>>> C:\downloads dir c:
>>
>> Shows contents of downloads
>>
>>> C:\downloads dir c:\
>>
>> Shows contents of c drive
>
>
> Yes, that's all well-known on windows.  The question was, how does the
Java File object handle it?   Does it give the correct result as above?
And going back to the original question, how should these paths be
normalized?

Let's hope this looks right, pasting code from Android device...

*import* java.io.File;

*import* java.net.URI;

*import* java.net.URISyntaxException;

*import* java.util.ArrayList;

*import* java.util.List;



*public* *class* Demo

{

*public* *static* *void* main(String[] args)

{

List paths = *new* ArrayList(2);

paths.add("file:/c:");

paths.add("file:/c:/");



*for* (String x : paths)

{

*try*

{

URI uri = *new* URI(x);

File f = *new* File(uri);

System.*out*.println(f.getAbsolutePath());

}

*catch* (URISyntaxException e)

{

e.printStackTrace();

}

   }

}

}

Re: context root with relative path

[David kerber]

On 4/21/2016 11:33 AM, Leo Donahue wrote:

Chris,

On Apr 21, 2016 9:15 AM, "Christopher Schultz" 
wrote:


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

--


On Windows 7 from a command prompt:


C:\downloads dir c:

Shows contents of downloads


C:\downloads dir c:\

Shows contents of c drive


Yes, that's all well-known on windows.  The question was, how does the 
Java File object handle it?   Does it give the correct result as above? 
 And going back to the original question, how should these paths be 
normalized?




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: context root with relative path

[Leo Donahue]

Chris,

On Apr 21, 2016 9:15 AM, "Christopher Schultz" 
wrote:
>
> 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
>
> --

On Windows 7 from a command prompt:

>C:\downloads dir c:
Shows contents of downloads

>C:\downloads dir c:\
Shows contents of c drive

Leo

Re: context root with relative path

[Christopher Schultz]

Konstantin,

On 4/20/16 8:31 AM, Konstantin Kolinko wrote:
> 2016-04-19 22:42 GMT+03:00 Mark Thomas :
>> 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 , 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 >> 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

Re: context root with relative path

[David kerber]

On 4/20/2016 12:07 PM, Dimitar Valov wrote:

System.out.println(new File("C:").exists()); prints true, so I guess it
works okay.


All that means is that it does something.  That doesn't means it's doing 
the correct thing.  That *should* be checking the existence of the 
"current" directory, which is always going to succeed.  The question is, 
is it actually checking for the existence of the root directory?  And 
what does


new File("C:\").exists()

give you?  And is it different?





On Wed, Apr 20, 2016 at 3:31 PM, Konstantin Kolinko 
wrote:


2016-04-19 22:42 GMT+03:00 Mark Thomas :

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 , 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 /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.

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org







-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: context root with relative path

[Caldarale, Charles R]

> From: Dimitar Valov [mailto:dimitar.va...@gmail.com] 
> Subject: Re: context root with relative path

> System.out.println(new File("C:").exists()); prints true, so I guess it
> works okay.

Depends on the definition of "okay"; that only tells us that the C drive's 
current directory is present.  As Konstantin pointed out, the normalization 
should have produced "C:\" - which will also pass the exists() test.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: context root with relative path

[Dimitar Valov]

System.out.println(new File("C:").exists()); prints true, so I guess it
works okay.

On Wed, Apr 20, 2016 at 3:31 PM, Konstantin Kolinko 
wrote:

> 2016-04-19 22:42 GMT+03:00 Mark Thomas :
> > 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 , 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  >> 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.
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: context root with relative path

[Konstantin Kolinko]

2016-04-19 22:42 GMT+03:00 Mark Thomas :
> 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 , 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 > 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.

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: context root with relative path

[Caldarale, Charles R]

> From: Mark Thomas [mailto:ma...@apache.org] 
> Subject: Re: context root with relative path

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 , for example tomcat
> is put inside the application's META-INF.

Not that it's pertinent to the resource retrieval problem, but a path attribute 
of "/" is never correct ("" might be what is wanted).  But since path 
attributes on  elements located in META-INF/context.xml are not 
allowed, it doesn't really matter for this particular issue.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: context root with relative path

[David kerber]

On 4/19/2016 4:13 PM, Dimitar Valov wrote:

Hi Mark,

Yes, it is sensitive, that's why I'm suggesting such simple solution. For
me the issues comes because of AbstractFileResourceSet::file -> absPath =
absPath.substring(absoluteBase.length() + 1); and if
(!canPath.equals(absPath)). This + 1 should account for the /. However we
cannot count on not having the / at the end of absPath.


Why not explicitly check for the existence of the trailing "\", rather 
than assuming it's (non)existence and just checking the string length?


I think Mark is saying that you have found an inconsistency, and pending 
further testing thinks that there should be changes made so that you get 
back what you supplied to those functions.  I.E., if you gave it a 
trailing "\" as an argument, you'll get one back, and if not, you won't.





I've played with specifying paths that end with / and without, and I think
that there's no way that the current implementation can be configured
correctly:
   * if path like ../../ is used it is normalized to path ending with / =>
the substring will consume the first character of the filename.
   * if path like ../.. is used it is normalized to path ending .. (which is
even worse), but this can be documented out, otherwise a method like
Path.normalize should be used or implemented.
   * if path like ../../app or ../../app/ is used everything works
correctly, but this is bacause StandardContext::fixDocBase takes care to
delete the last /.

I think that if fixDocBase does something to strings like ../../../ it will
break the results returned from RequestUtil.normalize, i.e. deleting the
last / and the normalizing it will produce path ending with /.. which will
once again not work.

The behaviour of org.apache.tomcat.util.http.RequestUtil is quite similar
but different from the one getting unique file path (Path.normalize). And
then if (!canPath.equals(absPath)) is comparing two quite similar things
,but not the same  "things". I think that with java.io.File APIs there's
nothing that can give the needed behaviour (the getCanonicalPath will
resolve symlinks)

Best Regards,
Dimitar Valov

On Tue, Apr 19, 2016 at 10:42 PM, Mark Thomas  wrote:


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 , 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 /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 "/".

Mark

Re: context root with relative path

[Dimitar Valov]

Hi Mark,

Yes, it is sensitive, that's why I'm suggesting such simple solution. For
me the issues comes because of AbstractFileResourceSet::file -> absPath =
absPath.substring(absoluteBase.length() + 1); and if
(!canPath.equals(absPath)). This + 1 should account for the /. However we
cannot count on not having the / at the end of absPath.

I've played with specifying paths that end with / and without, and I think
that there's no way that the current implementation can be configured
correctly:
  * if path like ../../ is used it is normalized to path ending with / =>
the substring will consume the first character of the filename.
  * if path like ../.. is used it is normalized to path ending .. (which is
even worse), but this can be documented out, otherwise a method like
Path.normalize should be used or implemented.
  * if path like ../../app or ../../app/ is used everything works
correctly, but this is bacause StandardContext::fixDocBase takes care to
delete the last /.

I think that if fixDocBase does something to strings like ../../../ it will
break the results returned from RequestUtil.normalize, i.e. deleting the
last / and the normalizing it will produce path ending with /.. which will
once again not work.

The behaviour of org.apache.tomcat.util.http.RequestUtil is quite similar
but different from the one getting unique file path (Path.normalize). And
then if (!canPath.equals(absPath)) is comparing two quite similar things
,but not the same  "things". I think that with java.io.File APIs there's
nothing that can give the needed behaviour (the getCanonicalPath will
resolve symlinks)

Best Regards,
Dimitar Valov

On Tue, Apr 19, 2016 at 10:42 PM, Mark Thomas  wrote:

> 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 , 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  > 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 "/".
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: context root with relative path

[Mark Thomas]

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 , 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  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 "/".

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org