On Sun, Sep 11, 2011 at 19:35, Craig White craigwhite@azapple.com wrote:

you'd still have it in bash_history though so it's really a poor idea to ever pass a significant password directly on the command line execution

• whether visible or not visible to ps. Much better is to be prompted

for the password instead...

mysql mysql -u root -p

and it will prompt

another option is to have ~/.my.cnf which already has your password

Craig

Actually, it's not in Bash history because I log in from a remote server like this: $ ssh -t dotan@1.2.3.4 "mysql -u root -pSECRET"

That, in turn, is actually aliased to something else. Therefore the login info does appear in my _local_ alias file, but if that is compromised then there is no reason to assume that ~/.ssh/ isn't also compromised, and vice versa.

Additionally, one could add a space before a command to prevent it from being written to the history, I do this when encrypting files with openssl.

On Mon, Sep 12, 2011 at 03:30, Craig White craigwhite@azapple.com wrote:

not exactly sure what point you are trying to make about being compromised - not all that relevant but you can still just use -p option without the password and get prompted for the password which actually solves your question.

The password is 32 random characters covering all of ASCII. I don't want to go look for it several times a day.

Also, since MySQL is client/server you could probably use the mysql client on your local machine and connect to the server and use encryption but that isn't what you asked.

On the server MySQL only listens to localhost.

Also, presuming you are using bash on the originating machine, you would have it in bash_history, just on a different machine. The point I was trying to make is that it is generally a poor idea to put a password into a shell command whether mysql or whatever.

No, this is why I mentioned the alias. Only the alias shows in my local history, not the password.

On Mon, Sep 12, 2011 at 23:25, Craig White craig.white@ttiltd.com wrote:

create a proper .my.cnf file - problem solved

There are other users who have root access (yes, I know, bad idea but it's not my box) who I don't want playing around in the mysql cli (I'm being a bully here, I know, but they are PHP guys). They can access MySQL via PHP and when something breaks it is in an environment that they are professionally expected to be proficient in. Not to be a jerk, but in any group of high-level-language programmers there is the one who will experiment on a production webserver instead of installing Linux on his machine at home. I started off as that guy! Yes, I know that the PHP guys can get the password by looking in the mysqlConnection.inc file that they typically include() so that sensitive information is not in the root path. Total security is not my goal, but rather reasonable obstacles to friendly, non-malicious entities.

In other words, I want a pony. I want a single command to log in from my own machine right to the mysql cli, but I don't want anyone else to have simple access to that cli. Actually, I pretty much do have that pony. I just wondered how ti worked.

Thanks!

On Tue, Sep 13, 2011 at 18:42, Craig White craig.white@ttiltd.com wrote:

I'm sorry, I was trying to make a point about the methodologies employed to better enhance security **especially** when you have other users on the same system... the point is that you should never use any command line function that includes the password for many reasons including ps visibility (and note that even if ps output suppresses the passed parameters, there still might be evidence in /proc), bash_history (or other shell histories), or just simply keylogging (which can be done by anyone with a shell on the system, su or not). The idea is that you open a connection first, establish a method of encrypted communications and then are prompted for the password or in the case of mysql, the ~/.my.cnf will send the password at the appropriate time.

As for other users... I don't understand the logic of forcing them to use a PHP program vs. a CLI. MySQL fully supports the notion of users/permissions/grants, etc. and their access should be controlled using the integrated ACL system of MySQL, not some artificial notion of security based on CLI vs. WebApp. If they have DB Admin privileges using a GUI, there's nothing that they can't do in the GUI that they could do in a CLI except that the CLI is likely more effective and efficient and reinforces good habits/practices.

Craig

From a technical point of view you are 100% right. The goal is not to

thwart malicious intent, but rather to discourage the use of the mysql cli as an experimentation platform. If any particular dev is motivated enough to find and use the cli than all the better for him, if he wants it that bad then he is probably already familiar with it.

It is exactly the "effective and efficient" bit that I am worried about! (no WHERE clause on DELETE, for one example).

On Mon, Sep 12, 2011 at 05:37, Devin Reade gdr@gno.org wrote:

Getting back to the original question, it is a feature of mysql (not of CentOS per se), but there's nothing that stops other (C) programs from doing something similar.  Shortly after startup, a programmer can set things up so that command line arguments (or in this case one of them) is hidden from anyone from viewing the process table.

However, even using this mechanism there is a window where, if someone looks at the process table at the right time, they will see the password in cleartext.

So, despite the mysql programmers trying to minimize the chance of leaking the password it is still a risk and so the advice others have given about -p (without the password) and .my.cnf is still the best option.

Thanks. I did not realize that this window of opportunity exists. Considering the circumstances, I think that it is a fair tradeoff.

Thank you for the information!

On Wed, Sep 14, 2011 at 01:27, John Beranek john@redux.org.uk wrote:

You can even do this in something like Perl, here you just modify '$0'.

I did not realize that the cli arguments are mutable.