Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
24.02, 24.08.0, 25.01.1
-
None
-
None
Description
When invoking maxctrl with explicit user name and password the password can be seen in the clear in ps output, e.g.:
$ maxctrl --user=admin --password=mariadb
|
...
|
$ ps aux | grep maxctrl
|
vagrant 1898 0.0 0.0 2608 536 pts/0 S+ 11:01 0:00 /bin/sh /usr/bin/maxctrl --user=admin --password=mariadb
|
vagrant 1899 4.3 2.8 603328 58004 pts/0 Sl+ 11:01 0:00 node /usr/share/maxscale/maxctrl/maxctrl.js --user=admin --password=mariadb
|
On the server side command line tools obfuscate password parameters so that they can't be retrieved from ps output, maxctrl should do the same:
$ mysql --user=repl --password=Secret23! --host=master
|
...
|
$ ps aux | grep mysql
|
vagrant 1999 0.0 0.4 20176 8912 pts/0 S+ 11:06 0:00 mysql --user=repl --password=x xxxxxxx --host=master
|
We should handle this consistently across all tools, including maxctrl.
Attachments
Issue Links
- is blocked by
-
MXS-4553 Rewrite maxctrl
-
- Open
-
Activity
But it still doesn't help with the problem at hand: a malicious user could get it form
{ps}output and then use it to perform their own
{maxctrl}actions by simple copy and paste
Is it possible to introduce a new option in the maxctrl to pass the
encrypted password in the command line, something like below
maxctrl --user=admin --encryptedpass='6E46705E97E8B1F4317AD17884E765FAACF32726'
that wouldn't help as it would still be visible in ps output and could be copied from there
This probably would involve rewriting /proc/<pid>/cmdline as modifying the original argv from Node.js is probably extremely difficult and not that reliable. /proc/self/cmdline doesn't seem to be writable which probably means it's not possible to fix this without rewriting MaxCtrl in C/C++.
Given that there's still a small window during which the plaintext password is visible even when it's overwritten, I'd say the best thing to do would be to just not pass passwords on the command line if seeing them is a problem.
With MXS-5449 fixed in the upcoming releases, a way to avoid passing plaintext passwords via command line arguments is to encrypt them with maxpasswd.
For older versions, there are safer means of providing passwords than passing them via options:
# Pass it manually via stdin
|
# [markusjm@monolith build-develop]$ bin/maxctrl -u admin --password='' list servers
|
Enter password: *******
|
┌─────────┬───────────┬──────┬─────────────┬─────────────────┬──────────┬─────────────────┐
|
│ Server │ Address │ Port │ Connections │ State │ GTID │ Monitor │
|
├─────────┼───────────┼──────┼─────────────┼─────────────────┼──────────┼─────────────────┤
|
│ server1 │ 127.0.0.1 │ 3000 │ 0 │ Master, Running │ 0-3000-9 │ MariaDB-Monitor │
|
├─────────┼───────────┼──────┼─────────────┼─────────────────┼──────────┼─────────────────┤
|
│ server2 │ 127.0.0.1 │ 3001 │ 0 │ Slave, Running │ 0-3000-9 │ MariaDB-Monitor │
|
├─────────┼───────────┼──────┼─────────────┼─────────────────┼──────────┼─────────────────┤
|
│ server3 │ 127.0.0.1 │ 3002 │ 0 │ Slave, Running │ 0-3000-9 │ MariaDB-Monitor │
|
├─────────┼───────────┼──────┼─────────────┼─────────────────┼──────────┼─────────────────┤
|
│ server4 │ 127.0.0.1 │ 3003 │ 0 │ Slave, Running │ 0-3000-9 │ MariaDB-Monitor │
|
└─────────┴───────────┴──────┴─────────────┴─────────────────┴──────────┴─────────────────┘
|
|
|
# Write it into a file and pipe into stdin
|
[markusjm@monolith build-develop]$ echo "mariadb" > password.txt
|
[markusjm@monolith build-develop]$ cat password.txt|bin/maxctrl -u admin --password='' list servers
|
┌─────────┬───────────┬──────┬─────────────┬─────────────────┬──────────┬─────────────────┐
|
│ Server │ Address │ Port │ Connections │ State │ GTID │ Monitor │
|
├─────────┼───────────┼──────┼─────────────┼─────────────────┼──────────┼─────────────────┤
|
│ server1 │ 127.0.0.1 │ 3000 │ 0 │ Master, Running │ 0-3000-9 │ MariaDB-Monitor │
|
├─────────┼───────────┼──────┼─────────────┼─────────────────┼──────────┼─────────────────┤
|
│ server2 │ 127.0.0.1 │ 3001 │ 0 │ Slave, Running │ 0-3000-9 │ MariaDB-Monitor │
|
├─────────┼───────────┼──────┼─────────────┼─────────────────┼──────────┼─────────────────┤
|
│ server3 │ 127.0.0.1 │ 3002 │ 0 │ Slave, Running │ 0-3000-9 │ MariaDB-Monitor │
|
├─────────┼───────────┼──────┼─────────────┼─────────────────┼──────────┼─────────────────┤
|
│ server4 │ 127.0.0.1 │ 3003 │ 0 │ Slave, Running │ 0-3000-9 │ MariaDB-Monitor │
|
└─────────┴───────────┴──────┴─────────────┴─────────────────┴──────────┴─────────────────┘
|
|
|
# Store the password in a configuration file
|
[markusjm@monolith build-develop]$ cat << EOF > maxctrl.cnf
|
> [maxctrl]
|
> user=admin
|
> password=mariadb
|
> EOF
|
[markusjm@monolith build-develop]$ chmod 0600 maxctrl.cnf
|
[markusjm@monolith build-develop]$ bin/maxctrl -c maxctrl.cnf list servers
|
┌─────────┬───────────┬──────┬─────────────┬─────────────────┬──────────┬─────────────────┐
|
│ Server │ Address │ Port │ Connections │ State │ GTID │ Monitor │
|
├─────────┼───────────┼──────┼─────────────┼─────────────────┼──────────┼─────────────────┤
|
│ server1 │ 127.0.0.1 │ 3000 │ 0 │ Master, Running │ 0-3000-9 │ MariaDB-Monitor │
|
├─────────┼───────────┼──────┼─────────────┼─────────────────┼──────────┼─────────────────┤
|
│ server2 │ 127.0.0.1 │ 3001 │ 0 │ Slave, Running │ 0-3000-9 │ MariaDB-Monitor │
|
├─────────┼───────────┼──────┼─────────────┼─────────────────┼──────────┼─────────────────┤
|
│ server3 │ 127.0.0.1 │ 3002 │ 0 │ Slave, Running │ 0-3000-9 │ MariaDB-Monitor │
|
├─────────┼───────────┼──────┼─────────────┼─────────────────┼──────────┼─────────────────┤
|
│ server4 │ 127.0.0.1 │ 3003 │ 0 │ Slave, Running │ 0-3000-9 │ MariaDB-Monitor │
|
└─────────┴───────────┴──────┴─────────────┴─────────────────┴──────────┴─────────────────┘
|
I would imagine that it's still an improvement over unencrypted passwords as you'd need access to the encryption keys in order to be able to use that password.
Perhaps we should consider not allowing passwords to be passed on the command line as it's inherently insecure. The environment of a process is hidden from users so MAXCTRL_USER and MAXCTRL_PASSWORD would be more secure.