You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "Roytman, Alex" <Ro...@peacetech.com> on 2005/01/06 21:55:59 UTC
Pluggable mechanism for loading context config files
Dear Tomcat developers,
I would like to implement context config file encryption. It is a pretty useful feature since passwords to various resources are stored in those files
Unfortunately the way how context config files are read is hard coded (InputSource for Digester is created from FileInputStream) and does not let me do so.
It would be great if tomcat 5.5 provided some pluggable ConfigFileLoader in HostConfig (and may be on Engine level as well) to return InputStream for a given config file name (or decorator for FileInputStream ).
It would be also great if it were possible to register context config file extensions other then *.xml - it would allow to use *.exml for encrypted XML config files (will save us a test of the file to se if it is encrypted or plain text)
If it is not possible to make this enhancement may be you could re-factor ContextConfig class so it can be effectively subclassed and its input stream logic altered
All you would need to do is to factor out
protected void processContextConfig(InputStream) {
}
from
protected void processContextConfig(File file) {
if (log.isDebugEnabled())
log.debug("Processing context [" + context.getName() + "] configuration file " + file);
// Add as watched resource so that cascade reload occurs if a default
// config file is modified/added/removed
context.addWatchedResource(file.getAbsolutePath());
InputSource source = null;
InputStream stream = null;
try {
if (file.exists()) {
stream = new FileInputStream(file);
source =
new InputSource("file://" + file.getAbsolutePath());
} else if (log.isDebugEnabled()) {
log.debug("Context [" + context.getName() + "] configuration file " + file + " not found");
}
} catch (Exception e) {
log.error(sm.getString("contextConfig.defaultMissing") + file);
}
if (source == null)
return;
if (contextDigester == null){
contextDigester = createContextDigester();
}
synchronized (contextDigester) {
try {
source.setByteStream(stream);
.....
If processContextConfig(InputStream) is available, we can override this method, read from encrypted stream, decrypt create decrypted stream in memory and pass it to the original (superclass) processContextConfig(InputStream)
Thank you very much for your assistance
Alex Roytman
roytmana@peacetech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Pluggable mechanism for loading context config files
Posted by Remy Maucherat <re...@apache.org>.
Roytman, Alex wrote:
> Dear Tomcat developers,
>
> I would like to implement context config file encryption. It is a pretty useful feature since passwords to various resources are stored in those files
> Unfortunately the way how context config files are read is hard coded (InputSource for Digester is created from FileInputStream) and does not let me do so.
>
> It would be great if tomcat 5.5 provided some pluggable ConfigFileLoader in HostConfig (and may be on Engine level as well) to return InputStream for a given config file name (or decorator for FileInputStream ).
> It would be also great if it were possible to register context config file extensions other then *.xml - it would allow to use *.exml for encrypted XML config files (will save us a test of the file to se if it is encrypted or plain text)
>
> If it is not possible to make this enhancement may be you could re-factor ContextConfig class so it can be effectively subclassed and its input stream logic altered
>
> All you would need to do is to factor out
>
> protected void processContextConfig(InputStream) {
>
> }
>
>
> from
>
> protected void processContextConfig(File file) {
>
> if (log.isDebugEnabled())
> log.debug("Processing context [" + context.getName() + "] configuration file " + file);
>
> // Add as watched resource so that cascade reload occurs if a default
> // config file is modified/added/removed
> context.addWatchedResource(file.getAbsolutePath());
>
> InputSource source = null;
> InputStream stream = null;
> try {
> if (file.exists()) {
> stream = new FileInputStream(file);
> source =
> new InputSource("file://" + file.getAbsolutePath());
> } else if (log.isDebugEnabled()) {
> log.debug("Context [" + context.getName() + "] configuration file " + file + " not found");
> }
> } catch (Exception e) {
> log.error(sm.getString("contextConfig.defaultMissing") + file);
> }
> if (source == null)
> return;
> if (contextDigester == null){
> contextDigester = createContextDigester();
> }
> synchronized (contextDigester) {
> try {
> source.setByteStream(stream);
>
> .....
>
> If processContextConfig(InputStream) is available, we can override this method, read from encrypted stream, decrypt create decrypted stream in memory and pass it to the original (superclass) processContextConfig(InputStream)
You should be able to easily plug your own Host or Context listener for
configuration.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Pluggable mechanism for loading context config files
Posted by Mark Thomas <ma...@apache.org>.
Alex,
I would vote '-1' for any such addition Tomcat.
Let me explain why by way of a simple example. Let us assume that Tomcat
requires a plain text user name and password to connect to a database.
First of all, consider the security risks if the information is stored
in an unencrypted file somewhere on the server. Assuming that this file
is not publicaly available, only users with access to the machine can
access the file. With a little more configuration and possibly some
network security only users with physical access to the machine can
access the file and read the password.
If one or more 'untrusted' users has physical access to the machine it
is pretty much game over from a security point of view. With physical
access there are a whole host of potential attacks I can think of that
would enable an attacker to gain access to the file.
Therefore, all we are trying to do is protect the contents of a file
from a group of users all of whom are authorised to see it. What is the
point?
Looking at it from another perspective, lets say we do encrypt the file.
How does Tomcat decrypt it? Tomcat needs access to the decryption key.
If this is in a file, the file needs to be protected. How do you do
this? This is the same problem we had before. We have just added another
layer. It is a chicken and egg situation with no solution. The same
applies to providing the password via some 'service'. How does the
Tomcat process authenticate to this service to retrieve the password? It
needs some credentials. Where are these stored? In a file... and so we
start all over again...
One thing that could work is not placing the password in a file at all
but requiring it to be entered at start up. However, this exchanges a
confidentiality security problem for an availability one - if the system
fails it can only be restarted when there is someone present who knows
the password. Also, people being people, there is a strong chance this
password will get written down and your security has just got worse
rather than better.
Ultimately, the best thing you can do is leave the password unencrypted
in a file and make sure the machine is electronically and physically
secured with the right policies and procedures to ensure that it remains
secure.
Regards,
Mark
Roytman, Alex wrote:
> Dear Tomcat developers,
>
> I would like to implement context config file encryption. It is a pretty useful feature since passwords to various resources are stored in those files
> Unfortunately the way how context config files are read is hard coded (InputSource for Digester is created from FileInputStream) and does not let me do so.
>
> It would be great if tomcat 5.5 provided some pluggable ConfigFileLoader in HostConfig (and may be on Engine level as well) to return InputStream for a given config file name (or decorator for FileInputStream ).
> It would be also great if it were possible to register context config file extensions other then *.xml - it would allow to use *.exml for encrypted XML config files (will save us a test of the file to se if it is encrypted or plain text)
>
> If it is not possible to make this enhancement may be you could re-factor ContextConfig class so it can be effectively subclassed and its input stream logic altered
>
> All you would need to do is to factor out
>
> protected void processContextConfig(InputStream) {
>
> }
>
>
> from
>
> protected void processContextConfig(File file) {
>
> if (log.isDebugEnabled())
> log.debug("Processing context [" + context.getName() + "] configuration file " + file);
>
> // Add as watched resource so that cascade reload occurs if a default
> // config file is modified/added/removed
> context.addWatchedResource(file.getAbsolutePath());
>
> InputSource source = null;
> InputStream stream = null;
> try {
> if (file.exists()) {
> stream = new FileInputStream(file);
> source =
> new InputSource("file://" + file.getAbsolutePath());
> } else if (log.isDebugEnabled()) {
> log.debug("Context [" + context.getName() + "] configuration file " + file + " not found");
> }
> } catch (Exception e) {
> log.error(sm.getString("contextConfig.defaultMissing") + file);
> }
> if (source == null)
> return;
> if (contextDigester == null){
> contextDigester = createContextDigester();
> }
> synchronized (contextDigester) {
> try {
> source.setByteStream(stream);
>
> .....
>
> If processContextConfig(InputStream) is available, we can override this method, read from encrypted stream, decrypt create decrypted stream in memory and pass it to the original (superclass) processContextConfig(InputStream)
>
>
> Thank you very much for your assistance
>
> Alex Roytman
> roytmana@peacetech.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org