MySQL Bugs: #25805: ps shows mysql password

Bug #25805	ps shows mysql password
Submitted:	23 Jan 2007 22:20	Modified:	17 Jan 2011 9:49
Reporter:	David Zokaites	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MySQL Server: Command-line Clients	Severity:	S4 (Feature request)
Version:	5.0.27	OS:	Solaris (Solaris)
Assigned to:		CPU Architecture:	Any

Description:
Title:  ps shows mysql password 

This bug report is closely related to the following bug reports:
Bug #11952, "Client shows passwords passed on command line"
Bug #9966,  "mysqld_multi stop show clear password listing processes with ps"
Bug #1423,  "plaintext password in OS"

DBAs are fond of writing scripts to automate various database
maintenance processes.  Scripts to do so often use "here documents" as
inputs to database clients as in the following example:

mysql --user=admin --password=value <<-END > log.file 
      command1;
      command2; 
      END

The problem with this process is that it exposes the password to the
unix ps command.  Command line arguments (typed in one shell) are
visible to other shells simply by typing "ps -ef" on the unix command
line.  

If the mysql password is not provided on the command line, then mysql
(the command interpreter) reads the password from the tty and not
standard input.  Unfortunately, that prevents putting the password in
the here document to keep it from exposure via ps.  The design of
mysql requires that scripts expose a password to ps.  At any
installation where security is even a minor consideration, exposing a
password to ps is simply unacceptable.  If a null password is provided
on the command line, then mysql should read the password from stdin
and not from a tty.  If you don't wish to change the operation of the
current "--password" command line option, then a new option should be
provided with the desired functionality.

While I noted this problem specifically with mysql, it probably
appears in multiple mysql unix command line clients.

Granted, it is possible to put a password in ~/.my.cnf, but then we
would have a cleartext password in a unix file.  Security analysts
warn against such things, even when the unix file is protected by 600
security mode.  

When I write database scripts, I frequently utilize the following
construct: 

vendorClientX -arg1 -arg2 <<-END > log.file2
      `password decrypt process`
      command1; 
      command2; 
      END

This protects the password from visibility via ps, keeps the password
out of the script, and prevents the password from appearing in
cleartext. 

David Zokaites
DBA/Software Engineer 

How to repeat:
The description clearly shows how to reproduce the bug.

Suggested fix:
See the description.

Thank you for a problem report. This problem is discussed in bug reports you mentioned and some solutions are presented in the manual already, http://dev.mysql.com/doc/refman/5.0/en/password-security.html.

As far as I understand, you are asking to re-implement mysql so that password is read from stderr, not /dev/tty? This is a feature request (S4) then. Do you agree?

I do also remember myself as system administrator creating a fake /dev/tty with passwords on Solaris x86, to solve a bit similar problem (regular changing of passwords for Solaris users :)

Valeriy,

Yes, I am asking for a change to mysql so that password is read from stdin instead of /dev/tty.  It is inconsequential if this change is described as a “feature request” or as a “security bug.”

Concerning your other point, how would I create a fake
/dev/tty to accept a password?

David

As current behaviuor is explicitely described in the manual (with all the options to make scripts as secure as possible with current implementation), I can not call this a bug. 

This is the way how it is implemented not only in MySQL. Can you give me example of the other RDBMS that will allow to pass password to script in essentially more secure way, on Solaris?

As you propose a new, maybe a bit more secure idea, I think, this is a reasonable feature request. I can not tell you is it really possible to implement it any time soon - let the developers decide.

As for "fake" /dev/tty, you can do something like:

1. mv /dev/tty /dev/tty.real
2. /touch /dev/tty
3. chmod 400 /dev/tty
4. chown whoever:whatevergroup /dev/tty
5. cat <<EOF >/dev/tty
... whatever you want to be read from /dev/tty in your script, line by line
EOF
6. Start your script
7. Restore /dev/tty back, ASAP:

rm /dev/tty
mv /dev/tty.real /dev/tty

Something similar worked for me once. 

But, please, check this approach, and use it (on your own risk) with as few concurrent users/processes as possible - /dev/tty has some information that is not what other scripts/people expect.

The Sybase client, isql, runs on Solaris.  It reads the password from stdin - and not a tty.  Isql has the password security functionality I seek from MySql.  

Sybase, of course, is a commercial RDBMS.

If Sybase did it, why MySQL can't... To me it is absolutely reasonable feature request to be considered by developers. I'll try to escalate it's consideration.

I am still not sure it will make MySQL much more secure, though.

What you want to do is called security by obscurity - if you run a program to decrypt a password, others can do it too - and discover your password. A password that can be decrypted is no more secure than a password in cleartext.

But if you still want to generate a password on the fly, use a config file in a socket:

  $ mkfifo my-super-secret-socket;
  $ (echo '[client];' echo -n 'password='; decrypt-password) > my-super-secret-socket &
  $ mysql --defaults-extra-file=my-super-secret-socket ...other-arguments...

It is now possible to write your own authentication framework with 5.5. I think this would add enough features to satisfy most user requirements. For instance you could set up a series of one time only accounts without having to flush privilege access in MySQL. I think this bug report can be closed. Georgi?

Based on the excellent analysis done by Serg and Valeriy and the new developments that we have in mysql 5.5 that provide real secure alternatives to script writers (and not security by obscurity) I'm closing this feature request as I'm not aware of a really secure way to pass a password from a script.
This is probably why mysql command line utility went for the only viable alternative (to read it from a tty instead of standard in).