Lmhelp1 wrote:
On 2014-03-12 11:32 PM, André Warnier [via Tomcat] wrote:
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.

That's it, I only miss the write permission for the owner group which is "tomcat6".

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.

Ok. This is what I was looking for.

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

For now, I do a "chmod g+w my_webapp" manually.

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.

Yes, indeed.

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.

I see.

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.

I see.

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).

Another time maybe :).

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.

Giving the write permission to the owner group of the directory "my_webapp" which is "tomcat6" including "user1" is safe, isn't it?
("user1" does have a shell).


Yes, I cannot really think off-hand of any serious problem that this may cause.
Basically, it all depends on the context.
If this is a one-off thing that you are doing, on your personal website, on a server on which there is no really critical information and which is not open to all on the Internet etc.. then it is one context. You still have to be a bit careful so that this does not make your server into an ideal base for a hacker, to use it to do nasty things elsewhere. And you don't want to open your site to script kiddies who have nothing better to do in life than crashing other people's work (there are people like that).
But it is not critical.

Another context entirely is if this is a professional website that you are setting up for an important customer which you cannot afford to lose, or if this is a "design pattern" for an application which you intend to reproduce hundreds of times in the future. In that case, you want something that is airtight, that you can easily reproduce, update and maintain, and that will work under Windows as well as Linux.
("umask" for example would not).
And you would also want something that is not going to be constantly flagged as insecure by security audit programs. They may have a set pattern of permissions that they expect, and they might not like that your webapp directory is "writeable by group". Also, there is no guarantee that the webapps directory of a servlet engine would be writeable at all. It could be located on some read-only device or filesystem. In theory, the webapps directory is supposed to contain only *code* to be executed and parameters to be read, not writeable data. For a writeable area, the servlet container offers specific writeable work directories (for temporary files etc.), which are *not* under the ../webapps/ dir.

Your choice.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to