Hi.
On 23.01.2018 12:11, Algirdas Veitas wrote:
Thanks for the quick reply George!
We could, but the data is still available, in this case a file, versus in
the output of "ps -ef | grep java". We can obviously encrypt the sensitive
information.
One idea, in order to support injecting Environment Variables would be to
support a syntax of
${env.DB_USER}
where if the subsitution property starts with "env", then the variable
could be retrieve by System.getEnv(...) otherwise System.getProperty(...).
and where does the environment variable value come from ?
Isn't this the forever-recurring same "chicken-and-egg" kind of issue that has been
repeated ad nauseam over hundreds of posts on dozens of forums already ?
Wherever you put any kind of "sensitive" information, in the end it has to be available
*somewhere* for Tomcat (or any other server) to read. And if you encrypt it, then the key
for decrypting it has to be available somewhere also.
And the answer to that, is always the same in the end, no matter how many recursions you
go through : the information has to be available somewhere in a file, readable *only* by
the user-id under which the server runs (and of course whoever can create such a file).
And if someone not authorized to do so, has access to that file, then you have bigger
problems than just with the server software.
On Mon, Jan 22, 2018 at 10:19 PM, George Stanchev <gstanc...@serena.com>
wrote:
Can you use catalina.properties? From the docs [1]
" All system properties are available including those set using the -D
syntax, those automatically made available by the JVM and those configured
in the $CATALINA_BASE/conf/catalina.properties file."
[1] https://tomcat.apache.org/tomcat-7.0-doc/config/index.html
-----Original Message-----
From: Algirdas Veitas [mailto:apvei...@gmail.com]
Sent: Monday, January 22, 2018 4:02 PM
To: users@tomcat.apache.org
Subject: Using Environment variables instead of Java -D properties for
context.xml substitution
Hi,
We have a context.xml under $TOMCAT_HOME/conf that looks like this:
<Resource name="jdbc/theDB"
auth="Container"
type="javax.sql.DataSource"
username="${DB_USERNAME}"
password="${DB_PASSWORD}"
driverClassName="oracle.jdbc.OracleDriver"
validationQuery="select 1 from dual"
testOnBorrow="true"
url="${DB_URL}"
/>
if we do something like this in setenv.sh, the substitution works great
export DB_USERNAME=xyz
export DB_PASSWORD=vvv
export JAVA_OPTS="$JAVA_OPTS -DDB_USERNAME=$DB_USERNAME"
export JAVA_OPTS="$JAVA_OPTS -DDB_PASSWORD=$DB_PASSWORD"
However, if on a linux box, if someone did a "ps -ef | grep java", they
would be able to see the actual values of these parameters.
theuser 127734 1 0 Jan19 ? 00:04:39 /opt/java/bin/java
-Djava.util.logging.config.file=/opt/mis/apps/jaspersoft/
tomcat/apache-tomcat/conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-DDB_USERNAME=xyz
-DDB_PASSWORD=vvv
Which our operations team does not want....
Is there any syntax that Tomcat can recognize to substitute true
environment variables (i.e. export DB_USERNAME=xyz) as opposed to Java
properties injected into the JVM by -D (i.e. export
DB_USERNAME=$DB_USERNAME) ? Haven't been able to find any documentation
on it, but thought would ask.
Thanks in advance,
Al
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
