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
wiser.
(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. ;)
-Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
