Could you clarify?
If you are using Apache, and you have *.jsp mapped correctly, your "programming resources" won't be shown to the world.
Since all servlets are under WEB-INF, all you have to be concerned about are JSP. Properties files, etc. go under WEB-INF, as well. Applciation architecture best practices says don't put anything critical in a JSP, so what's the big risk?
Going back to your earlier question, I simply set up a certain user account for both Apache and Tomcat. "webuser" or whatever. That user has restricted permissions and is a member of its own group (also "webuser" or whatever). Apache and Tomcat run as this user. Since developers should never have access to the command line on a production server, there's no problem.
John
Sonja Löhr wrote:
You are very right in that my greatest problem is to work out a pattern where to find the "static content" hides that Apache could perhaps serve a bit faster. Unfortunately, I can't tell Apache to serve ".gif" etc. but must come the other way round, perhaps ending up with URLs to single servlets. Many people cite security-reasons for the integration of the two, but all I've been bothered up to now is how to prevent Apache to show my programming ressources to the world (those unfortunately not located in WEB-INF).
I'll be thinking about doing it separately, you really calmed me down :-) thanks very much Sonja
----- Original Message ----- From: "Eric J. Pinnell" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Monday, September 01, 2003 4:28 PM
Subject: Re: permissions for Tomcat+Apache integration
Hi,
The question is do you need to secure your application from the outside world or do you need to secure it from users that might be logging on to your system? Or both?
Usually you want to go with the "both" scenerio.
But to keep it simple, pick a user that you want tomcat to run as. Untar Tomcat and chown -R tomcat jakarta-4.x.x (if the user is named "tomcat" which isn't a bad name for the Tomcat user ;)
Then just run it. It will be ok just like that. If you are running Tomcat and Apache on the same machine really look at why you are running Apache at all. It's a popular misconception that you _must_ run Apache in front of Tomcat. That couldn't be more wrong. Running Tomcat alone will save you the hassle of Apache and the connectors. However you do need to run Apache if you are going to use load balanceing and the apache modules. However most times people just have Apache pipe everything back to Tomcat. In this case you don't need Apache at all.
-e
On Mon, 1 Sep 2003, [iso-8859-1] Sonja Löhr wrote:
Hello!
Here is my second question, now concerning Apache+Tomcat integration on Linux: Could someone tell me a reasonable users, groups and file permissions structure for apache, the tomcat-files itself and a typical webapp? -
Java
security aside.
1. Is it a good idea at all to place the webapps under apache's document root, having to care about all WEB-INF and other sensible directories with "deny from all" ?
2. Which account in which group? Apache needs access to static files somewhere in the webapp. (Which may be very dispersed f.e. in case of cocoon). If a "tomcat" user and the "apache" user account are in the same group
with
restricted permissions, I can't assign permissions to a group of
developers,
just another owner (me ;-). Ok, may it be. Additionally, if tomcat
unpacks
war files, all resulting directories are owned by tomcat alone. So should
I
put the "apache user into the "tomcat" group?
3.How paranoid must I be about tomcat-files (server-directory f.e)? Tomcat needs write access to some directories, but certainly I don't know all processes tomcat.
You probably guess by now that I'm not grown up with Unix-systems. Spent my whole sunday with chmod and chown, now I would be very happy if someone told me something SIMPLE :-)
Thank you, Sonja
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
