tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Funk <>
Subject Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/ webapps/docs/changelog.xml
Date Fri, 14 Sep 2007 18:32:11 GMT
The basic concept behind the logic is:
- Look for prefix
- Replace with new base path

The new path replacement is done before the symlink and case check is 
done so those checks are still preserved. (Just with the new path alias).

If there is a security manager in play - it should already be blocking 
access to directories outside of one's control.

For file/directory redirection such as replacing requesting /foo and 
then redirecting to /foo/ - I will add (if this is accepted) an entry to 
the FAQ to strongly recommend replacements include the trailing / - such 
that a user shoudl enter: /foo/bar/=/docs/tmp/ AND NOT 
/foo/bar=/docs/tmp since wierd behaviors can arise since a request of 
/foo/barry/file.pdf would yield /docs/tmpry/file.pdf (notice the last ry 
being preserved). I left this behavior in instead of requiring a 
trailing / since ... well if someone wishes to shoot themself in the 
foot - I won't stop them.

For /WEB-INF/ handling - this does provide an ability to have WEB-INF 
live somewhere else on the filesystem other than the webapp. When I 
first made the patch - I thought about making an exception for that - 
but then decided not to since I couldn't ponder a reason security wise 
to do so.

 From a security point of view - the only gotcha I see is in a shared 
environment where you might suck in part of someone else's webapp in a 
shared environment. If this can be done - then it would be worthwhile 
adding a flag which would allow any aliasing to occur. Or a simpler 
alternative is if you are running with a security manager turned on - 
then aliasing is disabled.


Remy Maucherat wrote:
> Remy Maucherat wrote:
>> It's not a real veto anyway, but no proper review mechanism exists at 
>> the moment, and it's hard to integrate feature additions in 6.0.x 
>> without prior discussion.
> I did review the patch:
> - the syntax seems appropriate
> - I don't know if it allows redirecting a single fine, but I think it 
> should if it does not (I did not test it; at least the list feature 
> would not be working right now)
> - it seems like it will still validate going out of the remapped "base" 
> path, which is good
> - interaction with the webapp classloader, which might have special 
> handling for /WEB-INF on the file based resources, is a question mark 
> (compatibility with that would be good, if possible)
> - security wise, it needs to be verified if the security manager 
> prevents usage of the feature (normally it should, there are no 
> privileged actions)

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message