innobackupex script shows the password in the ps output, when its passed as a command line argument

Bug #907280 reported by Ovais Tariq on 2011-12-21
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona XtraBackup
Status tracked in 2.4
2.3
Medium
Hartmut Holzgraefe
2.4
Medium
Hartmut Holzgraefe

Bug Description

innobackupex script shows the password in clear-text in the output of 'ps' command, when the password is passed as a command-line argument.

Changed in percona-xtrabackup:
status: New → Confirmed
assignee: nobody → Alexey Kopytov (akopytov)
Changed in percona-xtrabackup:
status: Confirmed → In Progress
Alexey Kopytov (akopytov) wrote :

I don't see a way to fix this reliably. It is possible to change the process title that appears in ps output on some operating systems to hide the password. But:

- there will always be a relatively short period of time after the process is started and before the title is changed, when the password will still be visible in ps.
- it's not portable
- even after innobackupex changes the process title for its own process, it still calls the mysql command line client later with the same password on the command line, which has the same problem.

So it will just give a false sense of security, which is known to be even worse than a lack of security.

The only alternative to not have the password visible in ps is to add it to my.cnf and use that file with innobackupex. In case the configuration file containing the password must have different access attributes than the main my.cnf, the solution proposed in bug #740489 should work (which is a feature request for addition configuration file to be passed as --default-extra-file).

Changed in percona-xtrabackup:
status: In Progress → Won't Fix

One solution to a lot of the problem is to remove the madness of shelling out to 'mysql' as a sub-process, and use DBD::mysql instead.

We'd probably fix about 20 other bugs, known and unknown, if we did this. And the amount of work we've spent fixing things like mysql timeout bugs has already been more than it would take to just switch to using DBD::mysql like sane programmers do. I assume that the original design was due to some misguidance from a lawyer about GPL following a protocol or something like that :)

Alexey Kopytov (akopytov) wrote :

Baron,

On 22.12.11 21:03, Baron Schwartz wrote:
> One solution to a lot of the problem is to remove the madness of
> shelling out to 'mysql' as a sub-process, and use DBD::mysql instead.
>
> We'd probably fix about 20 other bugs, known and unknown, if we did
> this. And the amount of work we've spent fixing things like mysql
> timeout bugs has already been more than it would take to just switch to
> using DBD::mysql like sane programmers do.

I agree, and for proper Windows support we will have to go further and
convert innobackupex to C/C++, which will fix even more known and
unknown bugs.

Now that things have been ported to C/C++, and that the mysql command line client tries to overwrite password data, use the same technique to overwrite it in xtrabackup/innobackupex ps output, too:

https://github.com/percona/percona-xtrabackup/pull/289

Changed in percona-xtrabackup:
assignee: Alexey Kopytov (akopytov) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers