tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Securing Tomcat Context Descriptor
Date Sat, 20 Aug 2005 10:43:22 GMT
A couple of observations:

- If someone can read the context descriptor they pretty much own
Tomcat and probably the server as well. If this person is unauthorised,
you have big problems regardless of whether or not they have read-only 
access to the database.

- If the password is encrypted, where do you store the decryption key?
Tomcat still needs to be able to decrypt the password in order to use
it to access the database. At best, this is security by obscurity
which is not very good security at all.

You could write some custom code that required the password to be 
entered on the command line when Tomcat starts but this still has the 
following issues:

- If Tomcat goes down, you need someone who knows the password to 
restart it. If the group of people that know the password is small, 
you have an availability issue.

- Chances are that everyone who administers Tomcat will know this 
password. Given that these people should be the only ones with access 
at the OS level to the Tomcat configuration files there seems little 
point in going to all this trouble.

In my experience securing the configuration files (Tomcat & JVM) using 
OS file permissions is usually the appropriate course of action to 
take unless your security environment is very unusual.


Brett Parsons wrote:
> Hi All,
> There is a requirement on the server that we have Tomcat 5.0.28 deployed 
> that no username/password information can be stored in plaintext (in the 
> open).  Like many people, we are using JNDI datasources in our web 
> application.  The datasource connection information (including the 
> database username/password) is stored in the Tomcat Context Descriptor 
> under TOMCATDIR/conf/Catalina/localhost/myApp.xml.
> Does Tomcat provide a more secure way of storing the connection 
> information stored in these context deployment descriptors?  Has anyone 
> else run into the same problem and been able to solve it somehow?
> Thanks,
> Brett
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message