Remy Maucherat wrote:
I tested with the security manager, and it doesn't behave correctly.
If the context.xml inside a webapp is:
<Context>
<Resources className="org.apache.naming.resources.FileDirContext"
docBase="c:/foo" aliases="/mysecretpath/=c:/" />
</Context>
The docBase hack attempt doesn't do anything (it's overwritten, I
think), but the security manager does not prevent browsing the HD as the
policy grants all permissions to all JARs in lib.
I'm not too sure about the "portability" argument. If it was valid, then
we should add all proprietary features from all appservers right away. I
am not aware of JBoss having such a feature either (it does have
extensive CL configuration, though, but that is necessary due to its
default behavior).
In your test example - you need to use C:/ instead of c:/ for the drive
name. The case sensitive check was looking for C: instead of c:
> <Resources className="org.apache.naming.resources.FileDirContext"
> docBase="c:/foo" aliases="/mysecretpath/=C:/" />
IIRC, docBase is set by its container *after* the XML attributes are
set. (otherwise - we have a larger issue that a user can set a different
doc base via the Resources directive independent of the aliases directive)
So you are saying if the security manager is turned on (which restricts
file access) - it is ignored since FileDirContext is granted all
permissions? If that is the case - do we have a related issue with
AccessLogValve since absolute paths may be used there? (writing to
inappropriate places or files)
I mentioned in an earlier thread that I can add a check to see if there
is a security manager - and if one is present - then the alias option
would be disabled. Does this sound like something worth pursuing?
I am still relatively young to the community and haven't been around for
the 3.x - 4.x flame wars (or enough to get the full impact) but I guess
we should document somewhere that the mission of Tomcat "is to provide a
minimal set of functionality to service the Servlet and JSP
specification. It is designed to be easily to be easily embedded and
extended but core functionality will be minimal." With the above
statement - it is easily justified to then mark INVALID various feature
requests in Bugzilla. As well as advertise that the project will be
minimalist and encourage the use of the outside community to extend it
as needed. Or maybe everyone knew thus all along and this is one of
those days that I'm a little dense.
-Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
