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 : http://tomcat.apache.org/tomcat-7.0-doc/config/context.html
and see : http://tomcat.apache.org/tomcat-7.0-doc/deployer-howto.html
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
