This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Talk:Securing tomcat"
Line 20: | Line 20: | ||
[[User:Dledmonds|Darren]] 04:35, 9 January 2007 (EST) | [[User:Dledmonds|Darren]] 04:35, 9 January 2007 (EST) | ||
+ | |||
+ | ==Replacing Default Error Page== | ||
+ | Why only restrict the default error page on java.lang.Exception? The more inclusive java.lang.Throwable would seem to be the better choice, as it would prevent leakage of stack traces in the event of a java.lang.Error. |
Revision as of 03:48, 22 February 2008
What's the best way to acknowledge the contributions of others as I'd like to add some thanks to Kris Easter, Michel Prunet and Stephen More. This discussion area? In brackets after the article link from Java Project Roadmap ? Darren 08:58, 27 October 2006 (EDT)
I've added an acknowledgements section to the main page. Stephendv 11:58, 14 January 2008 (EST)
UNIX Permissions
> Change files in CATALINA_HOME/conf to be readonly (440)
Initially these are 600 (except for tomcat-users.xml which is 644 and Tomcat keeps it that way). Is there a need to make them group-readable?
> Make sure tomcat user has ... write (220 - yes, only write) access to CATALINA_HOME/logs
This doesn't work. I think the best that can be done here is 750 or 700.
Combatopera 15:53, 12 November 2006 (EST)
CATALINA_HOME/conf files updated to recommend chmod 400. tomcat-user.xml the same as tomcat doesn't write to it. Original file permissions for all these conf files were 600 when 5.5.20 was unpacked on a debian box.
CATALINA_HOME/logs directory updated to recommend chmod 300. Prevents tomcat user reading the logs within, but writing works fine for me - again after 5.5.20 was unpacked on a debian box.
Darren 04:35, 9 January 2007 (EST)
Replacing Default Error Page
Why only restrict the default error page on java.lang.Exception? The more inclusive java.lang.Throwable would seem to be the better choice, as it would prevent leakage of stack traces in the event of a java.lang.Error.