Hi.
Ok, so let's recurse..
On 23.01.2018 13:27, Algirdas Veitas wrote:
Andre, my apologies for bringing up a topic that has been repeated ad
nauseum.
We were thinking of a process like the following, which would eliminate
"the information has to available somewhere in a file" on the actual server
where Tomcat is running.
cd $TOMCAT_HOME/bin
set +o history
export DB_USERNAME=xyz
./startup.sh
..... once the process has started
unset DB_USERNAME
set -o history
This process does not eliminate the need to store the values of sensitive
information. But by supporting environment variables, one could eliminate
using catalina.properties or -DDB_USERNAME, which exposes the information
on the server. In our case, operations would get the data from a secure
vault and then run the above scripts. I suppose we could get the same
effect by modifying catalina.properties, starting the server and then
clearing catalina.properties, until the next restart...
When you mention "operations", you are talking about some persons, right ?
I omitted to mention this solution before, because it means, in the practice, that someone
has to be available, to restart Tomcat (for example, after a system reboot, an update
etc..). So this is not really scalable.
In such a case, the Tomcat startup script could also just prompt the "operations" for the
userid/password, on the console. No need to add the complexity of an encrypted vault.
Of course, it means that you need a group of people sharing that role, because persons go
on holidays sometimes. And unless the sensitive information is trivial to remember (and
thus insecure), it will need to be written down somewhere. As would the password for the
secure vault.
It is turtles all the way down.
Don't want to restart an old thread, so if preferred, we can stop the
discussion. Thank you for your time.
On Tue, Jan 23, 2018 at 6:50 AM, André Warnier (tomcat) <a...@ice-sa.com>
wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
