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