Hello,
I would agree that passing secrets on the command line is insecure and
in this case unnecessary, there is an easy fix for that and it will be
implemented.
Speaking of environment, AFAIK on modern systems it can be read only by
sufficiently privileged user, so I don't see how it is less secure than
a file (which will have to have the same permissions as
/proc/<PID>/environ). Could you elaborate how is it less secure than
using --defaults-extra-file?
AFAIK xtrabackup/mariabackup script does not support passing passwords
via file descriptor, so that option does not seem to be practical.
Kind regards,
Alex
On 2021-03-14 13:20, Marc Lehmann wrote:
On Thu, Mar 11, 2021 at 09:49:03PM +0200, Otto Kekäläinen
<o...@debian.org> wrote:
Thanks for looking into this and reporting it. Could you be a bit more
specific what the context is, who can view the command?
This is a rather old and wlel-known type of security issue.
Typically any local user can view the password. This data is also often
exposed in monitoring output, http status pages, smtp and so on.
The comandline and environment are simply the wrong places to expose
secret data - passwords should never be shown on screen in cleartext.
(That includes the environment, btw. storing secrets in environment
variables is similarly insecure).
How do you suggest the password would be passed?
The typical method that is employed in practise is passing it via a
file
descriptor. A bit less secure is using a (non-world-readable) file,
e.g.
using --defaults-extra-file.
