Algirdas,
> Am 23.01.2018 um 13:27 schrieb Algirdas Veitas <apvei...@gmail.com>:
>
> 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...
>
Where would you put that script with the text?
Well if you use a secure vault, then that script would have to know the
password to the full secure vault...
You get a feel for the problem?
Run Tomcat in a dedicated service user, make the conf only readable for him and
restrict the access to the user’s home/tomcat dirs...
The admins of the server will have access to all the information anyhow. But
any other users around will not be able to read the conf, even the java opts of
the process will be invisible.
Just my 2cts.
Peter
> 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
>>
>>
