This is a newbie security mistake; don't get
in the habit of doing this. I know, I know, all
of the "MySQL for newbies" books and websites
say to do this, but they apparently don't care
about security.

The thing is, you never, never, never want
to put a password on a command line, because
it is potentially visible through "ps" and the like
to other users. That isn't MySQL-specific, that
applies to everything.

Instead, use an interactive method for
setting passwords. If you use "-p" without
a following password, MySQL utilities will
prompt interactively for the password.

I know, I know, everyone assumes that you're
on a single user home machine with no other
users, so what's the big deal with revealing the
password to no one at all?

Simple: it's a bad habit to get into, because
eventually you'll be on a multi-user machine,
and you really really don't want to have bad
habits on this order of magnitude.

Also, as you become an expert, you'll increasingly
give advice to other people, and you want to
make sure you give good advice, not horribly
bad advice, so you'll want to develop good habits
for the sake of giving good advice.

So once again, the good habit to get into is this:
never put a plain text password onto a command
line with any tool in any environment. Never!

Whether or not passing the password on the command line or in a shell script is a security risk is debatable. First, let me show you something:

$ ps -efwww | grep mysql
bofh 4599 4571 0 20:24 pts/4 00:00:00 mysql -h db1 -u root -px xxxxxx

The password field that you see in there is not altered by me in any way. That's what the output of ps reports. The MySQL tools do a wonderful job in not showing the passwords in the process list. Not all tools are this considerate.

That aside, you must remember that command will be saved in .bash_history - which is normally only readable by the user (bofh in this case) and root. Storing such a password in a script will also possibly allow other system users to view the password if they can read the script. Of course, root can always read files.

I have a general policy at work on machines that I manage - Secure any scripts that may contain such passwords. Chown them to 700. If anybody can compromise the box to read those files, I have far more to worry about than the MySQL root password (which is super easy to override if you can restart mysqld).

Systems administration is not just about locking up the box so that it's barely useable. It's about maintaining a careful balance between security and useability for users.

I suppose a slightly better way to balance the situation might be to have a dedicated MySQL DB server that has no local user access, and the root mysql account is retricted to local logins. That's really only feasible if you have equipment to spare.

maybe you mean chmod the file to 700, foo

No he exactly meant what he said ;)
Maybe you should start informing urself prior to posting nonsense like that. :roll:

<ul id="quote"><h6>Isil`Zha wrote:</h6>No he exactly meant what he said ;)
Maybe you should start informing urself prior to posting nonsense like that. :roll:</ul>

Doesn't appear to be nonsense to me. The original poster said chown 700.
In every box I know of that would leave the file permissions alone and make
the new owner of the file whoever happened to be UID 700. chmod 700
makes much more sense given the context.

I'm still figuring out user account security for MySQL 4.0 and am sort of worried about the root user password reset functionality. At face value, it seems like it could be an easy way for someone to gain access to my databases by just resetting the password. I made sure to create my own secure login and password and deleted the root user completely from the users table and flushed all privileges, but the reset procedure that allows you to load the database in a "safe mode" without grant restrictions seems like a big hole to me. Does anyone have anything to offer up to the newbie?

Thanks,
David

BTW, here's my email address: dklanac@yahoo.com

Thanks.

wait we r supposed to open mysqladmin in bin rgiht?? cuz wen i try to open dat it opens then quickly closes up i dont know what to do

I have a question then ... what do you do about an sh script that your using for a Cron job? I used the "Daily database dumps, all nicely sorted" recipe and it has the userName/password hardcoded in the .sh file. I have CHOWN'd it to 700, but I am wondering -- is there a better way to secure the username and password?

<ul id="quote"><h6>he_who_wanders wrote:</h6></ul><ul id="quote"><h6>Isil`Zha wrote:</h6>No he exactly meant what he said ;)
Maybe you should start informing urself prior to posting nonsense like that. :roll:</ul>

Doesn't appear to be nonsense to me. The original poster said chown 700.
In every box I know of that would leave the file permissions alone and make
the new owner of the file whoever happened to be UID 700. chmod 700
makes much more sense given the context.khe khe keh

<ul id="quote"><h6>Doug Merritt wrote:</h6>
So once again, the good habit to get into is this:
never put a plain text password onto a command
line with any tool in any environment. Never!</ul>

I notice you have all of the answers yet never presented an actual solution.
Did you mention using SSH or any other encryption method for the n00bs to research?

hi just joining and hope i will learn more