I want to run mysql client, giving the password non-interactively.
The standard solution is this
mysql -u root -e "foo" -p < password_file
but my situation is this
produce_password | mysql -u root -p
Here, mysql prompts for a password, even though data is being piped in. (Yes, produce_password is emitting data; echo foo | mysql behaves the same way.)
The Internet seems to think the above should work, but the fact is it doesn't. The workaround would be
produce_password > password_file
mysql -u root -p < password_file
rm password_file
But let's say I don't want to do this (e.g. policy demands that this password never be written to the disk)
How can I make mysql take the password from the input process without prompting, as it would for a file?
With thanks to fancyPants for explaining the cause, here is a solution which meets my requirements. (The encrypted .mylogin.cnf with mysql_config_editor isn't right for me, but thanks.)
To satisfy the security policy, mount /ramfs as a ramfs temporary file system. Assume file permissions are suitably restrictive.
ramdir="/ramfs"
cnf="$(mktemp "$ramdir/this-script-name-XXXXX")"
pw="$(produce_password)"
cat >"$cnf" <<EOF
[client]
user=root
password="$pw"
EOF
mysql --defaults-extra-file="$cnf" -e 'select 1'
rm "$cnf"
the problem with that is the password shows up in the process list.
But you can do this.
mysql --defaults-file=<(echo '[client]'; echo 'user=USERNAME'; echo "password=$mysqlpassword";)
It shows up in the process list like this.
mysql --defaults-file=/dev/fd/63
so the <() creates a file handle to the output of your commands.
This works with command line options that are expecting a file.
I don't know how to explain this, but when you pipe something, the stdout of the first program is forwarded to the stdin of the second program. You somehow confuse this, with the command line or whatever. You can pipe something to mysql, of course, but whatever you pipe is handled after you've authenticated yourself.
The solution would be
mysql -u root -p$(produce_password)
This generates your password with whatever program you have there and puts it in the right place on your commandline (my english is bad, can't explain better). When you have it in a file you could do
mysql -u root -p$(cat file)
I don't know, why you want to do it this way anyway, but you might be interested in having an encrypted file with your credentials, that you can use to log in without specifying a password. Read more about it here.
The easiest way is to declare the environment variable MYSQL_PWD.
Example:
$ export MYSQL_PWD=$(produce the password if required)
$ mysql -h example.org -u username
Remember you should not use -p in this case.
Related
You can avoid re-entering mysql command line password by putting the queries into a file.
In my case, the later queries are not determined until after the first queries have finished.
This happens in a non-interactive script so running a mysql console is not an option.
Is there any notion of a session for mysql command line interactions? Or can I set it up to listen for commands on a local unix socket (the output is required to be returned)? Or something like that?
User #smcjones mentions using the .my.cnf file or mysql_config_editor. Those are good suggestions, I give my +1 vote to him.
Another solution is to put the credentials in any file of your choosing and then specify that file when you invoke MySQL tools:
mysql --defaults-extra-file=my_special.cnf ...other arguments...
And finally, just for completeness, you can use environment variables for some options, like host and password. But strangely, not the user. See http://dev.mysql.com/doc/refman/5.7/en/environment-variables.html
export MYSQL_HOST="mydbserver"
export MYSQL_PWD="Xyzzy"
mysql ...other arguments...
I don't really recommend using an environment variable for the password, since anyone who can run ps on your client host can see the environment variables for the mysql client process.
There are a few ways to handle this in MySQL.
Put password in hidden .my.cnf in the home directory of the user the script is running as.
[client]
user=USER
password=PASSWORD
Use mysql_config_editor
mysql_config_editor set --login-path=client --host=localhost
--user=localuser --password
When prompted to enter your password, enter it like you otherwise would.
IMO this is the worst option, but I'll add it for the sake of completeness.
You could always create a function wrapper for MySQL that appends your set password.
#! /bin/bash
local_mysql_do_file() {
mysql -u localuser -h localhost -pPASSWORD_NO_SPACE < $1
}
# usage
local_mysql_do_file file.sql
You can avoid re-entering mysql command line password by putting the queries into a file.
In my case, the later queries are not determined until after the first queries have finished.
This happens in a non-interactive script so running a mysql console is not an option.
Is there any notion of a session for mysql command line interactions? Or can I set it up to listen for commands on a local unix socket (the output is required to be returned)? Or something like that?
User #smcjones mentions using the .my.cnf file or mysql_config_editor. Those are good suggestions, I give my +1 vote to him.
Another solution is to put the credentials in any file of your choosing and then specify that file when you invoke MySQL tools:
mysql --defaults-extra-file=my_special.cnf ...other arguments...
And finally, just for completeness, you can use environment variables for some options, like host and password. But strangely, not the user. See http://dev.mysql.com/doc/refman/5.7/en/environment-variables.html
export MYSQL_HOST="mydbserver"
export MYSQL_PWD="Xyzzy"
mysql ...other arguments...
I don't really recommend using an environment variable for the password, since anyone who can run ps on your client host can see the environment variables for the mysql client process.
There are a few ways to handle this in MySQL.
Put password in hidden .my.cnf in the home directory of the user the script is running as.
[client]
user=USER
password=PASSWORD
Use mysql_config_editor
mysql_config_editor set --login-path=client --host=localhost
--user=localuser --password
When prompted to enter your password, enter it like you otherwise would.
IMO this is the worst option, but I'll add it for the sake of completeness.
You could always create a function wrapper for MySQL that appends your set password.
#! /bin/bash
local_mysql_do_file() {
mysql -u localuser -h localhost -pPASSWORD_NO_SPACE < $1
}
# usage
local_mysql_do_file file.sql
I've heard that directly inputting your password on the command line is a bad idea, because anyone could see the "secret" in
mysql -u root -psecret
by browsing history.
I have a password for my MySQL database stored in a text file with limited read permissions, and was wondering if it is safe to access it in the following way:
mysql -u root -p$(cat ~/.mysql_pass)
Browsing history, I see the command printed, not the literal value. So it seems like it's working the way I want it to.
I'm sure there are better ways of handling passwords, I would just like to know whether or not this one is leaving my password completely out in the open.
You've suggested using the following:
mysql -u root -p$(cat ~/.mysql_pass)
However, the subcommand will be expanded before mysql is executed and so even if this isn't available in the command history, it's entirely possible for someone to view the process list just after invocation and see your password.
I think a better approach is to use a mysql client options file and have the mysql command read the password from the options file.
Just type mysql -u root -p and you'll get a prompt to enter your password and it won't be stored in the history.
I have a user on my machine that is only supposed to run mysql. Is there any way that I can set the shell of that user to mysql and login using password and username?
I know how to change the shell to the mysql binary
usermod -s /usr/bin/mysql
That is working indeed, only I can't provide a username/password in the program. Usually user/pw are given as
mysql -u $USER -p
I can not provide parameters for a shell as in
usermod -s "/usr/bin/mysql -u $USER -p" # Does not work!
Also using a simple shell-script as shell does not work:
#!/bin/sh # mysqlShell
/usr/bin/mysql -u $USER -p
----
usermod -s mysqlShell # does not work
So how can I provide parameters to a program I use as a shell for a user?
Thanks to Tom Regner I could figure out a solution using .my.cnf containing
[client]
host=localhost
user=$user
password=$pass
disable-auto-rehash
where mysql is set to the shell. I still would like give the password manually but this is the best I found.
Setup a $HOME/.my.cnf file for the user
[client]
host=localhost
user=mysqluser
password=mysqlpass
then set a bash as login shell and put the following in $HOME/.bashrc
exec mysql --host=localhost dbname
that should do what you want, while the user in question just has to give one password (the system account password on login).
exec replaces the shell process with the mysql process.
If this does not work as expected, you may need to adjust $HOME/.bash_profile to source .bashrc:
[[ -f ~/.bashrc ]] && . ~/.bashrc
It might be enough to provide an appropriate .my.cnf and setting /usr/bin/mysql as shell, but this way you can pass arbitrary commandline options/flags to the mysql client.
You can do that by editing the user's account details in the /etc/passwd and change the default shell.
You need a login password (unless you set up ssh appropriately). Use the following command: sudo passwd username to change that login password.
You also need a mysql password. Use SET PASSWORD Mysql request.
If you want the user to be connected to some fixed database with some fixed password, code a small C wrapper (then, make the executable only executable by your Unix user) doing mysql_real_connect, or calling some exec function for mysql --user=username --password=password databasename but I don't recommend doiing the later (because ps aux will show the password, and that is a security risk).
Perhaps, since MySQL is free software, you could customize the source code of mysql for your particular needs.
Perhaps using a restricted shell and carefully configuring it is better.
I'm trying to use mysqldump to dump a schema, and it mostly works but I ran into one curiosity: the -p or --password option seems like it is doing something other than setting the password (as the man page and --help output say it should).
Specifically, it looks like it's doing what is indicated here: http://snippets.dzone.com/posts/show/360 - that is, setting the database to dump.
To support my somewhat outlandish claim, I can tell you that if I do not specify the --password (or -p) option, the command prints the usage statement and exits with an error. If I do specify it, I am immediately prompted to enter a password (!), and then the database specified in the --password option is dumped (or an error is given in the usual case that a password not matching any database name was specified).
Here's a transcript:
$ mysqldump -u test -h myhost --no-data --tables --password lose
Enter password:
-- MySQL dump 10.10
mysqldump: Got error: 1044: Access denied for user 'test'#'%' to
database 'lose' when selecting the database
So, what gives? Is this the way this is supposed to work? It surely does not appear to make sense nor does it match the official documentation. And finally, if this just the way it works, how am I meant to specify the password to be used in an automated job? Using expect???
I'm using mysqldump Ver 10.10 Distrib 5.0.22, for pc-linux-gnu (i486).
From man mysqldump:
--password[=password], -p[password]
The password to use when connecting to the server. If you use
the short option form (-p), you cannot have a space between the option
and the password. If you omit the password value following the
--password or -p option on the command line, you are prompted for
one.
Specifying a password on the command line should be considered
insecure. See Section 6.6, "Keeping Your Password Secure".
Syntactically, you are not using the --password switch correctly. As such, the command line parser is seeing your use of "lose" as a stand-alone argument which mysqldump interprets as the database name as it would if you were to attempt a simpler command like mysqldump lose
To correct this, try using --password=lose or -plose or simply use -p or --password and type the password when prompted.
Another option is to create the file ~/.my.cnf (permissions need to be 600).
Add this to the .my.cnf file
[client]
password=lose
This lets you connect as a MySQL user who requires a password without having to actually enter the password. You don't even need the -p or --password.
Very handy for scripting mysql & mysqldump commands.
I found that this happens if your password has special characters in it. The mysql password here has a ! in it, so I have to do ==password='xxx!xxxx' for it to work corrrectly. Note the ' marks.
Try placing a '=' in between --password lose like:
--password=lose
If you use -p, then there can be no space between the -p and the password, i.e. '-plose'.
I am not sure if it works for the --password version, but if you use -p you can specify the password immediately afterwards (the key is not to include a space):
mysqldump -pmypassword ...
Did you try --password=whatever-password-is ?
Perhaps I'm missing the question, but that is what I do to run the tool.
If you use the -p or --password without an argument, you will get a prompt, asking to insert a password.
If you want to indicate a password on the command line, you must use -pYOURPASSWORD or --password=YOURPASSWORD. Notice that there is no space after -p, and there is an "=" sign after --password.
In your example, mysqldump asks for a password, and then treats "lose" as the database name. If that was your password, you should have included a "="
The -p option does not require an argument. You just put -p or --password to indicate that you're going to use a password to access the database. The reason it's dumping the database named whatever you put after -p is that the last argument for mysqldump should be the name of the database you want to dump (or --all-databases if you want them all).
#Nathan's answer is also true. You can specify the password immediately following the -p switch (useful in scripts and such where you can't enter it by hand after executing the command).
--password[=password]
Here is the documentation
Maybe your user "test" doesn't have the permission to access your "lose" database?