You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Vishwa. K" <vi...@yahoo.com> on 2009/12/18 11:01:18 UTC
Tomcat 5.5.17 - allowLinking property - symbolic links
Tomcat 5.5.17
Solaris 5.10
Our Web Application is required to display hyperlinks to external files that reside outside the web application based on certain business rules. The users could then download these large PDF files.
We went ahead with the idea of symbolic links supported by Tomcat.
<Context path="/powerApp" allowLinking="true"/>
We deployed the application and created a symbolic link under the web application directory to point to another external directory on the same server. All the hyperlinks use the symbolic link.
The Application worked fine. When we undeploy the application, Tomcat seems to be deleting the war file, the exploded directory and also all
the external files that are present in the directory pointed to by the symbolic link!
I was expecting tomcat to delete only the war file, the exploded directory including the symbolic link, but not the external PDF files during an undeployment!
I googled on the net and found that this behaviour has been observed on both Tomcat 5.x and Tomcat 6.x but no proper explanation to this issue.
I was wondering if this is the expected behaviour of Tomcat in this scenario or is it a bug?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 5.5.17 - allowLinking property - symbolic links
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark,
On 12/22/2009 4:33 AM, Mark Thomas wrote:
> On 22/12/2009 08:58, Vishwa. K wrote:
>> thanks Mark,
>> But I was wondering why Tomcat did not remove the complete directory itself.(softlink target directory). It removed only the nested files in it during undeployment of the application.
>
> No idea. Permissions maybe? If that isn't it you'd have to look at the
> source code to find an explanation.
I'm guessing that something like this happens:
File layout:
webapps/symlink -> /foo/bar
/foo/bar/dir_a
/foo/bar/dir_b
/foo/bar/file_a
Tomcat tries to delete webapps/symlink recursively. The filesystem (or
maybe java.io.File) descends into webapps/symlink which points to
/foo/bar and collects the files in there (dir_a, dir_b, file_a) and
proceeds to delete them recursively. Once dir_a, dir_b, and file_a are
deleted, the recursion jumps back to the parent (which is
webapps/symlink, NOT /foo/bar) and deletes that.
Thus, the link is deleted but not the target directory.
You can confirm this behavior by running these commands:
mkdir -p foo/bar/dir_a
touch foo/bar/dir_a/file_a
mkdir -p foo/bar/dir_b
touch foo/bar/dir_b/file_a
touch foo/bar/file_a
ln -s foo/bar symlink
And then running this program with "symlink" as the first command-line
argument:
import java.io.File;
public class Rm
{
public static void main(String[] args)
{
File file = new File(args[0]);
delete(file);
}
public static boolean delete(File file)
{
boolean success = true;
if(file.isDirectory())
{
File[] children = file.listFiles();
for(int i=0; i<children.length; ++i)
success &= delete(children[i]);
success &= file.delete();
}
return success & file.delete();
}
}
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAksyO/oACgkQ9CaO5/Lv0PArFwCgijzHTUv0yaPn4kIBt+MPRkxt
YUUAniKGZgLGWdKyn6tn4eHzYUK4YPmI
=XUd+
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 5.5.17 - allowLinking property - symbolic links
Posted by Mark Thomas <ma...@apache.org>.
On 22/12/2009 08:58, Vishwa. K wrote:
> thanks Mark,
> But I was wondering why Tomcat did not remove the complete directory itself.(softlink target directory). It removed only the nested files in it during undeployment of the application.
No idea. Permissions maybe? If that isn't it you'd have to look at the
source code to find an explanation.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 5.5.17 - allowLinking property - symbolic links
Posted by "Vishwa. K" <vi...@yahoo.com>.
thanks Mark,
But I was wondering why Tomcat did not remove the complete directory itself.(softlink target directory). It removed only the nested files in it during undeployment of the application.
- Vishwa
--- On Fri, 12/18/09, Mark Thomas <ma...@apache.org> wrote:
> From: Mark Thomas <ma...@apache.org>
> Subject: Re: Tomcat 5.5.17 - allowLinking property - symbolic links
> To: "Tomcat Users List" <us...@tomcat.apache.org>
> Date: Friday, December 18, 2009, 10:05 AM
> On 18/12/2009 10:01, Vishwa. K
> wrote:
> > I was wondering if this is the expected behaviour of
> Tomcat in this scenario or is it a bug?
>
> It is expected behaviour.
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 5.5.17 - allowLinking property - symbolic links
Posted by Mark Thomas <ma...@apache.org>.
On 18/12/2009 10:01, Vishwa. K wrote:
> I was wondering if this is the expected behaviour of Tomcat in this scenario or is it a bug?
It is expected behaviour.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 5.5.17 - allowLinking property - symbolic links
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ingo,
On 12/18/2009 5:10 AM, Ingo Gambin wrote:
> Although i have to add, that adding the <Context...> directive to
> conf/Catalina/localhost/<name>.xml
> did not work for me on Tomcat 5.5.
Technically speaking, the path is not always
conf/Catalina/localhost/<name>.xml. Instead, it's:
conf/[Service name]/[Host name]/<name>.xml
where "service name" is whatever <Service name="[name]" is set to. The
default is "Catalina".
where "host name" is whatever <Host name="[name]" it set to. The default
host is "localhost".
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAksryAsACgkQ9CaO5/Lv0PCGwQCfbIZ1KapSEoH2a/b+hdlDvxAX
n5EAnRro23yPV/8lYDGzhTUnVAinMoeq
=te+N
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 5.5.17 - allowLinking property - symbolic links
Posted by "Vishwa. K" <vi...@yahoo.com>.
Thanks Ingo, Chris,
Out of curiosity, I had tried the fake Application or fake docBases root approach mentioned by Ingo. It worked for me on Tomcat 5.5.17 and Windows XP.
My fakeApp.xml (context.xml) was :
<Context docBase="C:\\temp\\fakeApp" path="/fakeApp"/>
I copied this into the directory:
TOMCAT_DIR/conf/Catalina/localhost
C:\\temp\\fakeApp is the directory containing the list of external PDF files that need to be served to the users. I had also created a WEB-INF directory with a web.xml file here.
My main web application had a page containing the href links to the external files that need to be downloaded to the user.
<a href="/fakeApp/test.pdf">test.pdf</a>
This approach seems to work. Upon undeployment of fakeApp using Tomcat Manager, only the fakeApp.xml was deleted from the TOMCAT_DIR/conf/Catalina/localhost directory. The directory and all the files under C:\\temp\\fakeApp remained intact. (unlike in the soft links approach!)
I did not bother testing on Unix, as I think it is quite likely to work on Unix also. The fake document base approach seems to be better than the soft links approach, (atleast it did not delete all the external files!) The disadvantage that I see is the loss of Security. Since it appears to be a seperate application, the security that is available in the original Application is not carried forward to the fake Application.
Anybody who knows the direct URL to the fake Application can download the external files.
In the end, we decided to write file-serving code ourselves in our servlet, in our original application. The directory containing the external PDF files, is located outside the $TOMCAT directory, is a configurable parameter to the web application. A few more lines of code...it doesn't look too bad! :)-
--- On Fri, 12/18/09, Ingo Gambin <IG...@brilliant.de> wrote:
> From: Ingo Gambin <IG...@brilliant.de>
> Subject: Re: Tomcat 5.5.17 - allowLinking property - symbolic links
> To: "Tomcat Users List" <us...@tomcat.apache.org>
> Date: Friday, December 18, 2009, 10:10 AM
> Hehe,
>
> this I learned only a few days ago. I hope you didn't loose
> valuable
> information.
>
> But yes, this is the expected behaviour.
>
> In order to solve the problem you just have to add 'fake'
> docBases ...
> see below in the answers I got from Chris.
>
> Although i have to add, that adding the <Context...>
> directive to
>
> conf/Catalina/localhost/<name>.xml
> did not work for me on Tomcat 5.5.
>
> Putting it into server.xml on the other hand worked
> perfectly.
>
> Best regards,
>
> Ingo
>
> Am Freitag, den 18.12.2009, 02:01 -0800 schrieb Vishwa. K:
> > Tomcat 5.5.17
> > Solaris 5.10
> >
> > Our Web Application is required to display hyperlinks
> to external files that reside outside the web application
> based on certain business rules. The users could then
> download these large PDF files.
> >
> > We went ahead with the idea of symbolic links
> supported by Tomcat.
> >
> > <Context path="/powerApp" allowLinking="true"/>
> >
> > We deployed the application and created a symbolic
> link under the web application directory to point to another
> external directory on the same server. All the hyperlinks
> use the symbolic link.
> >
> > The Application worked fine. When we undeploy the
> application, Tomcat seems to be deleting the war file, the
> exploded directory and also all
> > the external files that are present in the directory
> pointed to by the symbolic link!
> >
> > I was expecting tomcat to delete only the war file,
> the exploded directory including the symbolic link, but not
> the external PDF files during an undeployment!
> >
> > I googled on the net and found that this behaviour has
> been observed on both Tomcat 5.x and Tomcat 6.x but no
> proper explanation to this issue.
> >
> > I was wondering if this is the expected behaviour of
> Tomcat in this scenario or is it a bug?
> >
> >
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 5.5.17 - allowLinking property - symbolic links
Posted by Ingo Gambin <IG...@brilliant.de>.
Hehe,
this I learned only a few days ago. I hope you didn't loose valuable
information.
But yes, this is the expected behaviour.
In order to solve the problem you just have to add 'fake' docBases ...
see below in the answers I got from Chris.
Although i have to add, that adding the <Context...> directive to
conf/Catalina/localhost/<name>.xml
did not work for me on Tomcat 5.5.
Putting it into server.xml on the other hand worked perfectly.
Best regards,
Ingo
Am Freitag, den 18.12.2009, 02:01 -0800 schrieb Vishwa. K:
> Tomcat 5.5.17
> Solaris 5.10
>
> Our Web Application is required to display hyperlinks to external files that reside outside the web application based on certain business rules. The users could then download these large PDF files.
>
> We went ahead with the idea of symbolic links supported by Tomcat.
>
> <Context path="/powerApp" allowLinking="true"/>
>
> We deployed the application and created a symbolic link under the web application directory to point to another external directory on the same server. All the hyperlinks use the symbolic link.
>
> The Application worked fine. When we undeploy the application, Tomcat seems to be deleting the war file, the exploded directory and also all
> the external files that are present in the directory pointed to by the symbolic link!
>
> I was expecting tomcat to delete only the war file, the exploded directory including the symbolic link, but not the external PDF files during an undeployment!
>
> I googled on the net and found that this behaviour has been observed on both Tomcat 5.x and Tomcat 6.x but no proper explanation to this issue.
>
> I was wondering if this is the expected behaviour of Tomcat in this scenario or is it a bug?
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>