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 23:57:53 GMT
Hopefully I can get all the concerns in one email ...
[Pardon me if this is not the most coherent - I been on vacation this 
week and I was staining and putting sealer or some wood furniture and 
got too many fumes to the head ... but don't let that reflect badly on 
the patch ... that was done weeks ago .. I finally got around to 
cleaning up the rough edges on it before the final commit]

* Security by allowing new path exposure *
1) Its just as "easy" to write a wrapper to accomplish the same thing if 
one wishes to bypass the security.

2) If a deploy tool is used which is doing checks - adding an extra 
check to allow/deny/restrict scope should not be too hard to do. Since 
users can disable symlink checks in the same class (FileDirContext) - 
the same exposure could be had with a little more effort.

I'm not trying to hand wave the concerns away with the previous 2 
points. I've thought a while about how I can exploit this patch and most 
examples relied on assumptions which if the assumption were true - your 
system would have already been compromised.

* Servlet API Portability *
I chose this route since it is more portable. Other app servers provide 
the ability to do aliases. It really becomes a configuration exercise 
from appserverA to appserverB.

(Ignoring the alias issue at the moment) The beautiful thing about using 
JNDI as the method of serving resources is one can swap in WARDircontext 
instead of FileDirContext and the webapp code is none the wiser. In 
fact, I could create a JDBCDirContext which houses all resources as 
clobs/blobs and its STILL spec compliant and the webapp code is none the 

(Now back on topic .. And history of the project that uses the patch - 
well not this exact patch but one darn near close since the original 
patch was done against 5.0)
The reason for aliases is I had static resources that needed to be 
served securely as part of a webapp. I can easily secure them via a 
web.xml security constraint or ServletFilter but the resources needed to 
appear as part of a webapp. But these resources are sourced by a 
different Enterprise system. I cannot drop a WEB-INF and child 
directories into a legacy Enterprise directory. (nor mirror it via a 
copy of the files) I also wanted to use the DefaultServlet as the means 
to serve the files. These were just pdfs and similar binary assets. 
Nothing magically, but potentially messy with If-Modified-Checks and 
partial content requests. I'd rather not reinvent (or copy) the wheel. 
So in a nutshell I needed a way for the Enterprise sourced content to 
look like it was part of the webapp. I would think this would not be an 
isolated case particular to me.

* Portability *
So depending on your point of view - this is portable or not portable. 
My vantage point is it is portable since I am writing user land code 
which assumes everything is contained inside my webapp. I can then rely 
on the servlet container to pull from other areas of the file system 
when need be to make the webapp appear as one logical unit. In this case 
- the user code is extremely portable but the configuration is dependent 
on the servlet container providing support for aliases.

* Summary *
I wanted a way for resources from various areas in the filesystem to 
appear as part of the webapp such the ServletContext.getResource() 
didn't know or care that the some content while being served from a 
directory sourced by some Enterprise system looked like part of the webapp.

At the end of the day - I could have relied on symlinks to implement the 
  project that dealt with this issue - but then when I needed to mirror 
content to our cluster of servers - I would've needed special setup to 
create the symlink as well as special rules to ensure that file 
replication excluded the symlink and its contents. Adding a symlink was 
a "much easy" alternative.

Yes - this is potentially bloaty and I tried on my first pass to 
subclass FileDirContext but the the number of touch points was to high 
that doing it right inside FileDirContext felt like the better alternative.

I have noticed other projects in the past few years at my employer where 
aliases would've come in handy instead of relying on symlinks.

* PS Summary *
I'm glad I didn't try to bring up the topic of asking how we can somehow 
detect OS so for the case sensitive OS's we can have the case checks 
turned off automagically ... and in other cases provide a switch to turn 
off symlink checking globally since these 2 checks can involve a lot of 
extra stat() calls. ;)


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

View raw message