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

-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

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

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

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

-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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 >

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

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

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

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

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

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]