views:

360

answers:

4

I am writing a bash script that I plan to execute via cron. In this script, I want to execute a command against a MySQL database, something like this:

$ mysql -u username -ppassword -e 'show databases;'

For clarity and those not familiar with mysql, the "-u" switch accepts the username for accessing the database and the "-p" is for password (space omitted purposely).

I am looking for a good way to keep the username/password handy for use in the script, but in a manner that will also keep this information secure from prying eyes. I have seen strategies that call for the following:

  1. Keep password in a file: pword.txt
  2. chmod 700 pword.txt (remove permissions for all except the file's owner"
  3. Cat pword.txt into a variable in the script when needed for login.

but I don't feel that this is very secure either (something about keeping passwords in the clear makes me queasy).

So how should I go about safeguarding password that will be used in an automated script on Linux?

+1  A: 

The only truly safe way to guard your password is to encrypt it. But then you have the problem of safeguarding the encryption key. This problem is turtles all the way down.

When the good people who build OpenSsh tackled this problem, they provided a tool called ssh-agent which will hold onto your credentials and allow you to use them to connect to a server at need. But even ssh-agent holds a named socket in the filesystem, and anybody who can get access to that socket can act using your credentials.

I think the only two alternatives are

  • Have a person type a password.

  • Trust the filesystem.

I'd trust only a local filesystem, not a remote mounted one. But I'd trust it.

Security is hell.

Norman Ramsey
trust the filesystem = trust the sysadmin that manages the server
AJ
@AJ: Of course. If you don't trust your sysadmin, you may as well give up (or secede). Even an encrypted filesystem is not much protection against a malicious sysadmin who has insider access.
Norman Ramsey
A: 

I'll agree with Norman that you should have someone type the password. If you just supply the -p flag without an accompanying password, it will prompt the user for it.

Tor Valamo
No user to enter the password when it's a CRON job.
OMG Ponies
A: 

Please see the doc for some guidelines. an extra step you can take is to restrict the use of ps command for normal users, if they have the permission to access the server.

ghostdog74
A: 

One way you can obfuscate the password is to put it into an options file. This is usually located in ~/.my.cnf on UNIX/Linux systems. Here is a simple example showing user and password:

[client]
user=aj
password=mysillypassword
AJ
This will at least keep the info in one location (albeit in the clear). Does the option file get read when the mysql call is done in a script executed by cron?
shambleh
@shambleh, on my environment it does. I'm on Debian Etch (4.0).
AJ