Sorry. You are right. Of course the shell will resolve the vars and put the values in the process name. Been living in Bootique world for the last 2 years, so I thought of a different scenario of the env var being read not via System.getProperty(), but rather via System.getenv().
So yeah, "-D" is unsafe, but converting shell vars to Cayenne DI properties in the app "main" method should hide the secrets from the causal observer on the app server. Andrus > On Dec 19, 2017, at 9:45 AM, Musall, Maik <m...@selbstdenker.ag> wrote: > > >> Am 19.12.2017 um 06:56 schrieb Andrus Adamchik <and...@objectstyle.org>: >> >>> A disadvantage of this approach, though, is it puts the username/password >>> on the command-line and/or the process list, plus potentially exposes it in >>> command-line history, too. >> >> It doesn't if you are careful. Nothing prevents you from putting these in a >> startup script of your app (this is what I was kind of alluding to when I >> defined credentials as exported vars). From there you have lots of options >> depending on how paranoid you are: >> >> * restricting access to the script with UNIX permissions. >> * storing it on an encrypted drive. >> * creating the script dynamically on startup and then deleting when the app >> is started. >> >> The point is that with properties you have an easy mechanism separating your >> security solution away from your Java app. > > As long as those parameters end up as part of the java command line because > the shell resolves them and puts them there literally, they will still be > discoverable from the process list at runtime for every other user on the > machine. The java process itself could redact them from there, but of course > it doesn't. > > The credentials would need to live in a separate file with locked down > permissions, with that file being referenced by name in the java command line. > > Maik >
