Bernard Giannetti wrote:
Thanks - I'll try the second method. I don't know if I am or am not running
under a security manager. I've just got a standard install of Tomcat - so
whatever comes out of the box is what I'm running.
In addition to the comment by Chuck :
As far as I know, Ubuntu uses the same packages and package manager as
Debian.
In the Debian distribution, whether the Java security manager is active
for Tomcat or not, is determined by a setting in the file
/etc/default/tomcatxxx (with xxx depending on the version).
In that file, there is a line like
TOMCATxxx_SECURITY=yes
If you set it to "no" and restart Tomcat, it will run without security
manager.
About the security manager :
As far as I understand it, this is a Java feature aimed at limiting what
a Java application is allowed to do.
It is there to protect your system against
1) yourself, in the sense that it may block some unintended actions by
your own applications
2) others, IF your system is such that other people can upload and run
Java applications on your server, which might then do obnoxious things.
If neither of these conditions apply in your case, you can disable the
security manager.
If your webapp is such that it reads and writes files onto the
filesystem without going through one of the Tomcat embedded functions to
do so, then they can theoretically do whatever they please, as long as
the basic filesystem permissions allow them to do so, and Java's
security manager is not activated (see above).
Tomcat runs under a specific user-id (e.g. "tomcat5"). All webapps
running under Tomcat run in the same process, under that same user-id.
If these webapps need to read/write files in some directory on the
filesystem, then that directory needs to allow that user-id to do so.
You can achieve this for example by :
- set the target directory to belong to a new group xxx
- make the user tomcatxxx belong to that group xxx (as an additional group)
or use ACLs, if the filesystem supports it (and you are not turned off
by the cryptic setfacl/getfacl syntax and logic).
Be careful not to create security holes when you do that kind of thing.
Also, this kind of thing tends to be OS-specific, so if your application
must run in multi-platform context, choose a method that is portable.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org