BTW:
> Am 23.01.2018 um 13:56 schrieb Peter Kreuser <l...@kreuser.name>:
>
> 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
the commandline parameters (-D) are also in the tomcat logs, thus probably in
your backups and archives.
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
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
