3 ms·
Even with that command line, shell history needs to be disabled, or the shell needs to be configured to filter when it saves history (for example, the bash ign
by thwarted 3y ago
Even with that command line, shell history needs to be disabled, or the shell needs to be configured to filter when it saves history (for example, the bash ignorespace HISTCONTROL option is useful here). This is, of course, shell specific.
- 0xbadcafebee 3y agoActually they didn't pass a password so there's nothing secret in the shell history that needs hiding. You can also set the password as an environment variable in a file and load it at runtime. The benefit there is that if you use a shell script to load your settings before running your application, you have a universal method of setting and passing variables, because the script can call any program to retrieve the password in any way, and then pass the value via environment variable. Bonus that any application-deploying tools can now override the value too. Security concerns around env vars being visible in process lists are mostly red herrings. If you can list the processes you've already got a memory leak, RCE, etc. Even if you can get the password it should be impossible to connect to the database from anywhere other than the application anyway. If you can read memory and connect to a database from where an application is running, you've got bigger problems.