tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
Date Wed, 12 Mar 2014 22:31:09 GMT
Lmhelp1 wrote:
> Hello and thank you for your answer.
> On 2014-03-12 11:54 AM, André Warnier wrote:
>> If all you need to do, is to
>> 1) read those files, to look at them
>> 2) if they are ok, move them somewhere else
>> 3) if they are not ok, delete them
> That's it.
>> then (under Linux) you do not need write permissions to the files
>> themselves.
>> To be able to read a file, you need :
>> - read and "browse" (x) access to the directory where these files are,
>> and any directory above that one, up to "/".
>> To be able to move a file from one directory to another, you need write
>> permission to the source directory and the target directory (and not
>> necessarily to the file).
> Ok.
> In my case, the target directory is the webapp directory "my_webapp".
> This directory is created when "tomcat6" deploys the archive 
> "my_webapp.war" which I put into the "Tomcat" webapps container.
> By default, the owner of this directory is "tomcat6",
> the owner group is "tomcat6"
> and the permissions are "755".
> So as you see, unfortunately, the owner group doesn't have the write 
> permission :/

Ok, I understand : the target directory is not created by you, it is created by Tomcat, so

Tomcat sets these permissions, and they do not fit what you want to be able to do.

First, to my knowledge there is no standard way, by configuration alone, to tell Tomcat to

set these permissions differently when it creates that directory as a result of the 
deployment of your webapp's war-file.

But there are probably a dozen ways to do this anyway (and I don't know enough to think of

all of them).

One way of course, since Tomcat is Open Source, would be to find the place in Tomcat where

it does this, modify that code, and build your own modified Tomcat.  But that way is hard

and full of accidents waiting to happen, so you probably don't want to do that.

Another way would be to change the way in which you deploy your webapp, and that way 
itself subdivides into several sub-ways :
1) instead of deploying your webapp as a war-file (and let Tomcat explode it), you could 
already "explode" that webapp.war yourself, and deploy your application "statically". That

is, already create in advance the directory .../webapps/my_webapp, with the exploded 
contents of your war-file in it.  You could then set the permissions of the "my_webapp" 
directory once and for all, and Tomcat would probably not re-set them.
2) you could use a script to deploy your war-file programmatically, using the Tomcat 
Manager application to do it.  Tomcat would explode the war-file (creating the 
webapps/my_webapp dir in the process, with permissions 755); and then your script would 
re-set these permissions to what you want.
3) there are probably a couple more ways to do essentially the same, which I do not know 
and will leave it to someone else more qualified to suggest.

Another way would be to change the way in which your webapp "my_webapp" works.
(And here I assume that these files are "static files" - like images or html files, but 
not JSP files).
Currently, you (probably) just move the uploaded files somewhere under webapps/my_webapp/,

and leave it to Tomcat to serve those file when a browser requests them.

Instead of that, you could have an "active" webapp "my_webapp", which responds to browser

requests for those files, and which actively reads them and returns them to the client.
In such a case, the files would not need to be directly under ../webapps/my_webapp/, they

could be anywhere, including in some separate directory (preferably even not under the top

Tomcat directory), where your active webapp can find them. And that directory could have 
the permissions that you want, and Tomcat would never touch it.
To be clean and flexible, the path to that directory could be in a parameter in your 
webapp's web.xml, which would be read by your active webapp, and that is where it would 
look for those files.

I am sure that there are several cleverer ways to achieve the same result without having 
to do any real additional programming. For example by using a "servlet filter" inserted 
"around" your webapp, and which would do the real work (e.g. look up for 
"UrlRewriteFilter" in Google; it may well allow to do that kind of thing).

You may even find a way to cleverly use some code to modify on-the-fly the location where

Tomcat will look for the file (your appropriately permissive directory, where you moved 
the files), and then let Tomcat return it to the browser anyway.
(That's how I would do this, if we were talking about Apache httpd, instead of Tomcat. 
But I digress, this is a Tomcat list).

I believe that another way (at least under Tomcat 7 (the current version), may be to use 
the "aliases" attribute in the Context descriptor of your application.
See :
and see :
to understand how Tomcat deploys an application, and where that Context descriptor would 
need to be.
(Nite: you need to verify this, I have never used aliases under Tomcat and I do not really

know if that would be usable here).

The one solution which gives you the most control is the one where your own "my_webapp" 
webapp is the one which actually reads and returns the files to the browser, because that

is your code, and you can bend it in any way you want.
(Including for example, returning something nice to the client, when the file that he 
wants is not there).

Be careful that changing the permissions of your webapps/my_webapp directory itself, may 
weaken the security of your Tomcat website, because there may be other things in there 
than the files which you intend to serve to the clients.
That's why having these files somewhere else than directly under webapps/my_webapp may be

preferable in any case.  It also keeps these files nicely separated from your own files 
and JSP's and servlets and config files.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message