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.
-Tim
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
