tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <cos...@gmail.com>
Subject Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/FileDirContext.java webapps/docs/changelog.xml
Date Fri, 14 Sep 2007 18:49:17 GMT
I'm not sure the security discussion is that simple, this seems quite a
dangerous change.
Currently  the user is restricted  to the webapps/ directory ( well,  he can
add a context
with the base in /etc and expose passwd I guess - but hopefully if a deploy
tool is used
or some automation is done on adding webapps, it can be controlled ). At
least this
introduces one more risk.

It may also have some implications on other use cases - deployment ( the
current pattern
is that all files for a webapp are in one place ), replication ( i.e. if
someone wants same webapps
on a pool of servers ).

Also questions about servlet API - are the aliases considered as part of the
webapp and returned
as resources ? Portability ? Will anything break or be confusing ?

But the most important question I have - why at this level ? If you have
files in a different
 directory - just add a servlet that is configured to serve files from
there, doesn't have to
be a tomcat-specific feature.

Costin

On 9/14/07, Tim Funk <funkman@joedog.org> wrote:
>
> 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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message