----- Original Message ----- From: "Remy Maucherat" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Thursday, September 12, 2002 7:39 PM Subject: Re: [PATCH] for bug#12049: symlinked directories, jsp pages arenot served
> > On 13/9/02 1:14, "Remy Maucherat" <[EMAIL PROTECTED]> wrote: > > > > >> This bug is kind of annoying when there are lots of pages > > >> shared across multiple clients. The common practice we > > >> use on Tomcat 4.0.2 is to build symbolic links under each > > >> client that points to a centralized place to avoid file > > >> copying on deployment. > > >> > > >> With the new code in 4.1, the path check below prevents > > >> any symlinked pages from being served. I would like to > > >> have it removed. However, with these two lines removed, > > >> the code essentially retroback to 4.0.2 version with > > >> very minor changes. > > > > > > Obviously, those lines are for security reasons. > > > > > > -1 for the patch (at best, the check will be made optional). > > > > Hmm... I'm wondering what are the problems if that check is not > performed... > > I don't see major concerns in allowing symlinked files or directories... > > Well, it has the advantage of: > - preventing access if somehow there's a security problem which is later > found in Tomcat, which would otherwise allow browsing the HD > - it may be what fixed the path disclosure issues on Windows > > I will make the check optional (with a flag). +1 (if I knew how, I'd do it myself). I agree that the default should be to disable sym-links, but the webmaster (and, with my webmaster hat on, I can't use >= 4 without sym-links) should be able to say what he/she wants to trust. > > > Also, few lines below, the check should be done for OS/X as well, given > that > > the file system is case insensitive, and for Unix operating systems if > they > > mount network shared volumes in case those are case unsensitive (SMB with > > case insensitive FS on the other side, that kinda stuff)... > > Quite possibly. > > Remy > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
