Re: Using Environment variables instead of Java -D properties for context.xml substitution

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 1/23/18 9:04 AM, Mark H. Wood wrote:
> Well, there are several layers of problems here, with different
> ways of addressing them.
> 
> Command lines are available using 'ps', so any secrets written on
> the command line are visible to anyone able to get a session on
> that host, for the duration of the command.  There's no way around
> this that I know of.
> 
> Process environment variables may also be visible to all and
> sundry, so moving secrets from the command line to the environment
> just makes slightly more work for the snooper.  Removing them from
> the shell's environment after use may not help, because typically
> the environment is cloned when a process is forked, so the service
> process will have copies that aren't removed.

I would argue that environment variables are more secure than system
properties (when passed on the command-line) because accessing a
process's environment variables usually requires some appropriate
level of access, whereas 'ps' is open to everyone, of course.

But of course there are even better solutions...

> The people who wrote the Servlet spec. seem to me to have been 
> thinking that the context for an instance of an app. would be 
> generated by an installer program or by the container's management 
> tools.  You could write a simple script to generate a context 
> declaration which is customized for a specific instance.  Unlike
> the command line or the process environment, files (such as a 
> free-standing context declaration) can be protected by the 
> filesystem.  This is your best noninteractive bet.

+1

> As mentioned by another, the way to limit availability of 
> machine-readable secrets to the greatest extent is to require an 
> operator to type them in at startup.  However, you'll need to
> consider the consequences of this if your container is
> automatically started at system startup -- you may need a way to
> let an individual context's startup wait for an operator to appear
> without hanging the whole system startup procedure.  (Automatic
> startup is another common thing that the spec. authors seem to have
> believed to be Somebody Else's Problem.)

I have a few machines with encrypted filesystems on them and, because
I understand that having the fs password in a startup script is
tantamount to not having an encrypted filesystem at all, I have to
enter the password for the crypto fs every time the machine is
restarted. This happens maybe once per quarter (3 mos... more often
when kernel patches are coming out several times per day like
recently) and it's a giant pain in my neck. Unless it's absolutely
required, don't put a human process in where an automated process will d
o.

> For completeness:  in your own code, you'll also wish to ensure
> that you obliterate (not just discard) secrets as soon as you have
> no further need for them.  That means that, within the JVM, they
> should only ever exist in mutable objects (not String, for
> example).

I disagree. There is almost no way to scrub memory in a JVM process.
Hell, it's almost impossible to scrub memory even in a native process
due to the way that the OS virtualizes memory regions. The OS can
write a page to disk without you even knowing about it, and not your
secret is on the disk. Yes, there are ways to tell the OS not to swap
that memory, but at some point you end up writing more scrubbing code
than anything else.

Take the JVM example. Let's say that you have a secret that is only
required for a short amount of time. You read it in from somewhere and
put it into a char[] object. That char[] object is mutable and sure,
you can write 0x00 to all of the char values before you discard the
object and allow it to be collected by the GC. But before you have the
chance to scrub it, the memory manager can relocate the char[] object
to another place within the current (or even a different) heap region.
Without native code, there is no way to prevent that from happening.
The GC can even run during your scrubbing-operation and you end up
with a copy of a half-scrubbed secret sitting around in an
unpredictable memory location.

Let's say you decide it's super-important to scrub that memory and you
understand that you have to pin the object in memory to scrub it
properly. So you write a native method to pin/scrub/unpin the object.
Well, what was the history of that object *before* you tried to pin it?

Okay, now we have to go 100% native and pin our char[] object, read
the data from wherever, use it for authentication/signing/whatever,
then scrub and unpin the object. Oh, and don't forget to tell the OS
not to swap-out that page of memory in the meantime.

Bullet-proof, right?

Sorry, no. In the process of using that secret to
authentication/sign/whatever, you may find that the
authentication/signing/whatevering library makes a copy of the secret.
Say... for easy-access. Is that library scrubbing the memory? Not
sure. Let's say that library 

Re: Using Environment variables instead of Java -D properties for context.xml substitution

[Algirdas Veitas]

Thanks for the feedback. -Al

On Tue, Jan 23, 2018 at 11:05 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Algirdas,
>
> On 1/23/18 6:11 AM, 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.
>
> Use sane file permissions?
>
> While you are at it, why not just put the db username and password
> into your application's META-INF/context.xml file where they belong?
>
> > 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(...).
>
> We *could* do that, but why?
>
> Is there a reason to think that file permissions are easier to break
> than, well, file permissions (think /proc/[pid]/environ)?
>
> - -chris
>
> > On Mon, Jan 22, 2018 at 10:19 PM, George Stanchev
> >  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:
> >>
> >>  >> 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
> >>
> >
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlpnXV0dHGNocmlzQGNo
> cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjcvQ/8Dtu3ftae5LDBrqLD
> AZlkomVg2RnuaASPRIeX+wyDsT7+ojjIknJy3l2pw3z9F/7qp98JZR7AsDb8V+ma
> ifRuxWEUrfpHmf+Mant+1DlgF56B+o9zMJevD435XwJiH2P2G6OBnopYvq5StDlN
> GF0JN+HUtceastqw91P3SRj9DS8q2K36F6b75r5I+JmDXoDHecbtVXxMMwq55u6l
> jXY/FzIUAfxmJnsiWZaYZ2+oFdwe4rWxe6vLTKUyAi17w3g7UcXHpXHzq4s7YlKO
> zfqkThTnOUi9loRKQSzfOb6kIDMSmM+MHZ/JrXqRrPQ0h1GxOaea4Wnp5rBg4TBI
> 1fkCiSLbv6oa+olZsIqZCVESSSO1yeZYRkAolENqMyRX+vlDjzKJehyIF8LlsnvY
> TjITzqEYsp9xSC15JU1OACmRdkOr9d/dS+5hoKT96cfu11Y+bt5My2lYvxUzGHCH
> crdTs4j8C5TPN4mksasOOEfuEg5aad0nj5x2lb4meZwUGiQYxmn13JV8c7I0skOM
> NtJX2kSxOLFFIpHZpPbY+cds2oYkfZOGFAKjcye7SGRGhuGFMfGohzZDbXIcgMVK
> DeioYT+gc+r6Y2gSvzRPISdlzEeRi4oPrXM42vsRs2qvOaacManAqqIOhdAHdPsZ
> a4mP2K3f7yHoWBxCG3zhxjli56o=
> =MG1G
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Using Environment variables instead of Java -D properties for context.xml substitution

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Algirdas,

On 1/23/18 6:11 AM, 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.

Use sane file permissions?

While you are at it, why not just put the db username and password
into your application's META-INF/context.xml file where they belong?

> 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(...).

We *could* do that, but why?

Is there a reason to think that file permissions are easier to break
than, well, file permissions (think /proc/[pid]/environ)?

- -chris

> On Mon, Jan 22, 2018 at 10:19 PM, George Stanchev
>  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:
>> 
>> > 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
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlpnXV0dHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjcvQ/8Dtu3ftae5LDBrqLD
AZlkomVg2RnuaASPRIeX+wyDsT7+ojjIknJy3l2pw3z9F/7qp98JZR7AsDb8V+ma
ifRuxWEUrfpHmf+Mant+1DlgF56B+o9zMJevD435XwJiH2P2G6OBnopYvq5StDlN
GF0JN+HUtceastqw91P3SRj9DS8q2K36F6b75r5I+JmDXoDHecbtVXxMMwq55u6l
jXY/FzIUAfxmJnsiWZaYZ2+oFdwe4rWxe6vLTKUyAi17w3g7UcXHpXHzq4s7YlKO
zfqkThTnOUi9loRKQSzfOb6kIDMSmM+MHZ/JrXqRrPQ0h1GxOaea4Wnp5rBg4TBI
1fkCiSLbv6oa+olZsIqZCVESSSO1yeZYRkAolENqMyRX+vlDjzKJehyIF8LlsnvY
TjITzqEYsp9xSC15JU1OACmRdkOr9d/dS+5hoKT96cfu11Y+bt5My2lYvxUzGHCH
crdTs4j8C5TPN4mksasOOEfuEg5aad0nj5x2lb4meZwUGiQYxmn13JV8c7I0skOM
NtJX2kSxOLFFIpHZpPbY+cds2oYkfZOGFAKjcye7SGRGhuGFMfGohzZDbXIcgMVK
DeioYT+gc+r6Y2gSvzRPISdlzEeRi4oPrXM42vsRs2qvOaacManAqqIOhdAHdPsZ
a4mP2K3f7yHoWBxCG3zhxjli56o=
=MG1G
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Using Environment variables instead of Java -D properties for context.xml substitution

[Algirdas Veitas]

It does turtle all the way downbut it would "solve" having sensitive
information on the Tomcat server exposed either in a file or via "ps -ef |
grep java"  (and make sure they are not logged by Tomcat in the logs).

Whether using the original sequence of commands shown or "prompting the
operations persons(s)" as Andre suggested, the total amount of time that
the sensitive information would be exposed "in the clear" would be
minimized to seconds before a restart and seconds after Tomcat and it's web
applications have been successfully deployed.



On Tue, Jan 23, 2018 at 8:40 AM, André Warnier (tomcat) 
wrote:

> 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) 
>> 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 
 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

Re: Using Environment variables instead of Java -D properties for context.xml substitution

[Mark H. Wood]

Well, there are several layers of problems here, with different ways
of addressing them.

Command lines are available using 'ps', so any secrets written on the
command line are visible to anyone able to get a session on that host,
for the duration of the command.  There's no way around this that I
know of.

Process environment variables may also be visible to all and sundry,
so moving secrets from the command line to the environment just makes
slightly more work for the snooper.  Removing them from the shell's
environment after use may not help, because typically the environment
is cloned when a process is forked, so the service process will have
copies that aren't removed.

The people who wrote the Servlet spec. seem to me to have been
thinking that the context for an instance of an app. would be
generated by an installer program or by the container's management
tools.  You could write a simple script to generate a context
declaration which is customized for a specific instance.  Unlike the
command line or the process environment, files (such as a
free-standing context declaration) can be protected by the
filesystem.  This is your best noninteractive bet.

As mentioned by another, the way to limit availability of
machine-readable secrets to the greatest extent is to require an
operator to type them in at startup.  However, you'll need to consider
the consequences of this if your container is automatically started at
system startup -- you may need a way to let an individual context's
startup wait for an operator to appear without hanging the whole
system startup procedure.  (Automatic startup is another common thing
that the spec. authors seem to have believed to be Somebody Else's
Problem.)

For completeness:  in your own code, you'll also wish to ensure that
you obliterate (not just discard) secrets as soon as you have no
further need for them.  That means that, within the JVM, they should
only ever exist in mutable objects (not String, for example).

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: PGP signature

Re: Using Environment variables instead of Java -D properties for context.xml substitution

[tomcat]

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) 
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 
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:



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 

Re: Using Environment variables instead of Java -D properties for context.xml substitution

[Konstantin Kolinko]

2018-01-23 16:14 GMT+03:00 Peter Kreuser :
> BTW:
>
>
>> Am 23.01.2018 um 13:56 schrieb Peter Kreuser :
>>
>> Algirdas,
>>
>>
>>
>>> Am 23.01.2018 um 13:27 schrieb Algirdas Veitas :
>>>
>>> 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.
>

VersionLoggerListener can also be configured to log the environment
variables with logEnv="true". It is not the default setting though.


> ad nauseum.

The FAQ page:
https://wiki.apache.org/tomcat/FAQ/Password


Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Using Environment variables instead of Java -D properties for context.xml substitution

[Peter Kreuser]

BTW:


> Am 23.01.2018 um 13:56 schrieb Peter Kreuser :
> 
> Algirdas,
> 
> 
> 
>> Am 23.01.2018 um 13:27 schrieb Algirdas Veitas :
>> 
>> 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) 
>> 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 
 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:
> 
>   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"
> 

Re: Using Environment variables instead of Java -D properties for context.xml substitution

[Peter Kreuser]

Algirdas,



> Am 23.01.2018 um 13:27 schrieb Algirdas Veitas :
> 
> 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) 
> 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 
>>> 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:
 
 >>>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/
 

Re: Using Environment variables instead of Java -D properties for context.xml substitution

[Algirdas Veitas]

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...

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) 
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 
>> 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:
>>>
>>> >> 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
>
>

Re: Using Environment variables instead of Java -D properties for context.xml substitution

[tomcat]

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 
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:



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

Re: Using Environment variables instead of Java -D properties for context.xml substitution

[Algirdas Veitas]

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(...).





On Mon, Jan 22, 2018 at 10:19 PM, George Stanchev 
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:
>
> 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
>

RE: Using Environment variables instead of Java -D properties for context.xml substitution

[George Stanchev]

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:



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