On Tue, Sep 13, 2011 at 18:42, Craig White <craig.white at 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). -- Dotan Cohen http://gibberish.co.il http://what-is-what.com