ChatGPT解决这个技术问题 Extra ChatGPT

Suppress warning messages using mysql from within Terminal, but password written in bash script

When I tried running the following command on MySQL from within Terminal:

mysql -u $user -p$password -e "statement"

The execution works as expected, but it always issues a warning:

Warning: Using a password on the command line interface can be insecure.

However, I have to conduct the statement above using an environment variable ($password) that stores my password, because I want to run the command iteratively in bash script from within Terminal, and I definitely don't like the idea of waiting a prompt showing up and forcing me to input my password 50 or 100 times in a single script. So here's my question:

Is it feasible to suppress the warning? The command works properly as I stated, but the window becomes pretty messy when I loop over and run the command 50 or 100 times.

Should I obey the warning message and do NOT write my password in my script? If that's the case, then do I have to type in my password every time the prompt forces me to do so?

Running man mysql doesn't help, saying only

--show-warnings Cause warnings to be shown after each statement if there are any. This option applies to interactive and batch mode.

and mentions nothing about how to turn off the functionality, if I'm not missing something.

I'm on OS X 10.9.1 Mavericks and use MySQL 5.6 from homebrew.

The recommended way is to store your password in an option file (smth like [client] password=my_password in ~/.my.cnf). Surely it has some security implications too, but at least it's not accessible to anyone who can run ps, and you have control over it with file permissions.
mysql -u root password root -e "statement" > /dev/null ?
Oh by the way, you can also use something like Python pexcept. It can do terminal insertions and also handle feedback that the command gives. This way you can just skip that verbose output and strip of the actual output you want :)
The recommended way IMO penalizes the ones that do the right thing to protect the ones that do the wrong thing. If the password is stored inside a script file it will not show up with ps or in any log. That is the correct way to do this. Putting the file in an external file does help the ones that would cron the password but that is bad to start with. In the meantime scripts that have been running for years now fail and we need to modify them just because this warning comes up in the stderr.
For the recommended method whcih does not store the password in the clear, is detailed in dev.mysql.com/doc/refman/5.6/en/mysql-config-editor.html

G
Giacomo1968

If your MySQL client/server version is a 5.6.x a way to avoid the WARNING message are using the mysql_config_editor tools:

mysql_config_editor set --login-path=local --host=localhost --user=username --password

Then you can use in your shell script:

mysql --login-path=local  -e "statement"

Instead of:

mysql -u username -p pass -e "statement"

Remember that the --login-path has to come before all other arguments. I was trying mysqldump --tables --login-path=local and getting the error unknown variable 'login-path=local'.
This is working fine if we directly execute the shell file but not working if called from crontab
@NabeelArshad I think that this is because in your crontab the "home" for the user is not set (ENV vars in general) so in the crontab the client is not able to find the correct ~/.mylogin.cnf
@NamGVU, I'm not sure, however, I believe that this solution stores encrypted passwords.
So after all these comments, what is the solution that works for scripts that are called from crontab?
l
luke

I use something like:

mysql --defaults-extra-file=/path/to/config.cnf

or

mysqldump --defaults-extra-file=/path/to/config.cnf 

Where config.cnf contains:

[client]
user = "whatever"
password = "whatever"
host = "whatever"

This allows you to have multiple config files - for different servers/roles/databases. Using ~/.my.cnf will only allow you to have one set of configuration (although it may be a useful set of defaults).

If you're on a Debian based distro, and running as root, you could skip the above and just use /etc/mysql/debian.cnf to get in ... :

mysql --defaults-extra-file=/etc/mysql/debian.cnf


Note: --defaults-extra-file must be first option otherwise mysql complains with mysqldump: unknown variable 'defaults-extra-file.
Awesome alternative to the accepted answer. Definitely don't set the MYSQL_PWD variable....
Definitely a good option for versions below 5.6. Otherwise, I'd go with the accepted answer.
An alternative to making a temporary .cnf file is to do this in Bash: mysql --defaults-extra-file=<(printf "[client]\nuser = %s\npassword = %s" "$user" "$pwd") -e "statement". Since the printf is executed by Bash directly it doesn't show up in ps.
I needed to use --defaults-file rather than --defaults-extra-file, because the latter gave preference to the settings in ~/.my.cnf.
C
Community

One method that is convenient (but equally insecure) is to use:

MYSQL_PWD=xxxxxxxx mysql -u root -e "statement"

Note that the official docs recommend against it.
See 6.1.2.1 End-User Guidelines for Password Security (Mysql Manual for Version 5.6):

Storing your password in the MYSQL_PWD environment variable This method of specifying your MySQL password must be considered extremely insecure and should not be used. Some versions of ps include an option to display the environment of running processes. On some systems, if you set MYSQL_PWD, your password is exposed to any other user who runs ps. Even on systems without such a version of ps, it is unwise to assume that there are no other methods by which users can examine process environments.


This doesn't work in my bash script: Access denied for user 'root'@'localhost' (using password: NO)
In a script, you need to export MYSQL_PWD=whatever.
Because my query is very quick, I opted for this option. Then I set it to something bogus after executing the query.
In a script you don't need to run export, just place it all on one line: MYSQL_PWD=xxxxxxxx mysql -u root -e "statement"
MYSQL_PWD is documented in the 5.5, 5.6 and 5.7 client documentation, but omitted from the 8.0 documentation.
j
johnmontfx

If you wish to use a password in the command line, I've found that this works for filtering out the specific error message:

mysqlcommand 2>&1 | grep -v "Warning: Using a password"

It's basically redirecting standard error to standard output -- and using grep to drop all lines that match "Warning: Using a password".

This way, you can see any other output, including errors. I use this for various shell scripts, etc.


This is an excellent solution for use in one-liner tasks called in other tasks such as creating a Rake task for a Capistrano deployment.
Excellent and simple to mute that message, no need to touch anything in MySQL setup.
How would I use this with mysqldump where I already have a redirect for the SQL?
This is a really bad solution compared to the other ones here. It may fail with any subsequent version of MySQL should the text change, might not work in another locale either.
How about redirecting the error back to the stderr? (e.g. 1>&2)
B
Buttle Butkus

Here's how I got my bash script for my daily mysqldump database backups to work more securely. This is an expansion of Cristian Porta's great answer.

First use mysql_config_editor (comes with mysql 5.6+) to set up the encrypted password file. Suppose your username is "db_user". Running from the shell prompt: mysql_config_editor set --login-path=local --host=localhost --user=db_user --password It prompts for the password. Once you enter it, the user/pass are saved encrypted in your home/system_username/.mylogin.cnf Of course, change "system_username" to your username on the server. Change your bash script from this: mysqldump -u db_user -pInsecurePassword my_database | gzip > db_backup.tar.gz to this: mysqldump --login-path=local my_database | gzip > db_backup.tar.gz

No more exposed passwords.


J
JavaGuy

Easiest way is

mysql -u root -pMYPASSWORD -e "show databases" 2>/dev/null

Problem is this will suppress legitimate errors in your script as well.
Also you can create a log file 2>/var/log/myscript.log to log that errors.
use 2>/dev/null | grep -v "mysql: [Warning] Using a password on the command line interface can be insecure." to supress only the warning in question
Since 2>/dev/null already redirected to /dev/null - grep is not doing anything there. Redirection needs to go to 2>&1 to filter out just this single warning.
Я
Ярослав Рахматуллин

It's very simple. This is work for me.

export MYSQL_PWD=password; mysql --user=username -e "statement"

MYSQL_PWD is one of the environment variables that are used directly or indirectly by MySQL.

From the docs:

MYSQL_PWD - The default password when connecting to mysqld. Using this is insecure. See Section 6.1.2.1, “End-User Guidelines for Password Security”.


This is the only right answer here! works like a charm :)
Use of the MYSQL_PWD environment variable to specify a MySQL password is deprecated.
s
santiago arizti

ok, solution without temporary files or anything:

mysql --defaults-extra-file=<(echo $'[client]\npassword='"$password") -u $user -e "statement"

it is similar to what others have mentioned, but here you don't need an actual file, this part of the command fakes the file: <(echo ...) (notice there is no space in the middle of <(


this doesn't work if you already have a .my.cnf file in your ~/. with a password entry
I assume the fact that this didn't get any comments to the contrary, it is relatively secure. If that's the case, it is an awesome workaround in my opinion.
@stepanian The security issue reported by mysql[dump] comes from the fact that the password will appears in the list of processes running (see ps -ef | grep mysql). If you have it in a variable like shown in that statement, it's probably okay. However, if you have the password in clear instead of $password then it's not much better (the echo will be really fast, so as a hacker it's harder to get the info in this case, but still possible).
C
Community

You can also run the mysql_config_editor in your script to pass in the password when specifying the login path

expect -c "
spawn mysql_config_editor set --login-path=$mySqlUser --host=localhost --user=$mySqlUser --password
expect -nocase \"Enter password:\" {send \"$mySqlPassword\r\"; interact}
"

This starts an expect session which can be used in scripts to interact with prompts

See this post


Is that '>' really meant to be there?
yes '>' is meant to be there so that mysql_config_editor takes input from stdout. What is being passed from stdout to mysql_config_editor is the password you want this user to have Without the '>' then what happens is that the echo command is parsed and all that you would see is everything after the echo command
So, you mean to use the pipe operator "|", right? At least, in *nix and DOS, ">" will capture the STDOUT and write it to a file called "mysql_config_editor" in the current working directory.
Yes, you are correct, I have edited my original answer
D
David G.

A simple workaroud script. Name this "mysql", and put it in your path before "/usr/bin". Obvious variants for other commands, or if the warning text is different.

#!/bin/sh

(
(
(
(
(
    /usr/bin/mysql "$@"
) 1>&9 
) 2>&1
) | fgrep -v 'mysql: [Warning] Using a password on the command line interface can be insecure.'
) 1>&2 
) 9>&1

Whilst this answer is a little convoluted, I just upvoted it because it shits me so much to see answers that aren't explicitly wrong or are a little unconventional getting downvotes with no comments! No wonder David hasn't answered any other questions! He jumped in and tried to help with a novel solution and has been slammed with no explanation why! FU anonymous downvoters who don't leave comments!
+1 agree Jeremy Davis. This is convoluted, but when left with no other option this may be acceptable. It's definitely not wrong, unlike turning off warnings which has to be the stupidest idea ever!
@JeremyDavis Yes, this was convoluted, mainly because I wanted to show the work. It could possibly be done without any parentheses, but might have been less clear. This was also my first ever non-reading activity in all of stack exchange... after which I didn't touch it for a long time. Your comment was definitely appreciated.
@DavidG. - Glad my comment was of value to you. Also great to see that you're back and that your answer is now in positive territory. Personally, I don't think that down voting without commenting should be allowed... How is anyone meant to learn when they get slammed for having a go?!
Having said that, re-looking at your answer, I'm not convinced that a permanent solution (essentially wrapping mysql) to a temporary problem (suppressing an error message for usage in a single script) is the best way to go. IMO wrapping mysql in a function within the script (using your method here would be fine) is a superior approach. My 2c... :)
J
Joseph Shih

You can also just redirect the standard error STDERR output to /dev/null

So just do:

mysql -u $user -p$password -e "statement" 2> /dev/null


I would avoid this method as this since it would make legit errors harder to catch
B
Beta
shell> mysql_config_editor set --login-path=local
     --host=localhost --user=localuser --password
Enter password: enter password "localpass" here
shell> mysql_config_editor set --login-path=remote
     --host=remote.example.com --user=remoteuser --password
Enter password: enter password "remotepass" here

To see what mysql_config_editor wrote to the .mylogin.cnf file, use the print command:

shell> mysql_config_editor print --all
[local]
user = localuser
password = *****
host = localhost
[remote]
user = remoteuser
password = *****
host = remote.example.com

The print command displays each login path as a set of lines beginning with a group header indicating the login path name in square brackets, followed by the option values for the login path. Password values are masked and do not appear as clear text.

As shown by the preceding examples, the .mylogin.cnf file can contain multiple login paths. In this way, mysql_config_editor makes it easy to set up multiple “personalities” for connecting to different MySQL servers. Any of these can be selected by name later using the --login-path option when you invoke a client program. For example, to connect to the local server, use this command:

shell> mysql --login-path=local

To connect to the remote server, use this command:

shell> mysql --login-path=remote

What if I want to execute a mysqldump command as www-data user? www-data has no home directory... how do I setup the mysql_config_editor for www-data user?
N
Nestor Urquiza

From https://gist.github.com/nestoru/4f684f206c399894952d

# Let us consider the following typical mysql backup script:
mysqldump --routines --no-data -h $mysqlHost -P $mysqlPort -u $mysqlUser -p$mysqlPassword $database

# It succeeds but stderr will get:
# Warning: Using a password on the command line interface can be insecure.
# You can fix this with the below hack:
credentialsFile=/mysql-credentials.cnf
echo "[client]" > $credentialsFile
echo "user=$mysqlUser" >> $credentialsFile
echo "password=$mysqlPassword" >> $credentialsFile
echo "host=$mysqlHost" >> $credentialsFile
mysqldump --defaults-extra-file=$credentialsFile --routines --no-data $database

# This should not be IMO an error. It is just a 'considered best practice'
# Read more from http://thinkinginsoftware.blogspot.com/2015/10/solution-for-mysql-warning-using.html

l
lewiz

Another alternative is to use sshpass to invoke mysql, e.g.:

sshpass -p topsecret mysql -u root -p username -e 'statement'

Seems to work, but you have to remove 'username' from the command line, don't you?
C
Community

Here is a solution for Docker in a script /bin/sh :

docker exec [MYSQL_CONTAINER_NAME] sh -c 'exec echo "[client]" > /root/mysql-credentials.cnf' docker exec [MYSQL_CONTAINER_NAME] sh -c 'exec echo "user=root" >> /root/mysql-credentials.cnf' docker exec [MYSQL_CONTAINER_NAME] sh -c 'exec echo "password=$MYSQL_ROOT_PASSWORD" >> /root/mysql-credentials.cnf' docker exec [MYSQL_CONTAINER_NAME] sh -c 'exec mysqldump --defaults-extra-file=/root/mysql-credentials.cnf --all-databases'

Replace [MYSQL_CONTAINER_NAME] and be sure that the environment variable MYSQL_ROOT_PASSWORD is set in your container.

Hope it will help you like it could help me !


Not bad. I just used one call with a return in, e.g. docker exec [MYSQL_CONTAINER_NAME] sh -c 'exec echo "[client] [RETURN HERE] password=pa55" > /root/defaults' Using the --defaults-file it already picks up root too.
v
volingas

Define the helper:

remove-warning () {
    grep -v 'mysql: [Warning] Using a password on the command line interface can be insecure.'
}

Use it:

mysql -u $user -p$password -e "statement" 2>&1 | remove-warning

Tachaan! Your code is clean and nice to read

(tested with bash)


A
And

Personally, I use script wrapper to catch that error. Here is code sample:

#!/bin/bash

#echo $@ | cat >> /home/mysqldump.log 2>/dev/null
ERR_FILE=/tmp/tmp_mdump.err

# Execute dumper
/usr/bin/mysqldump $@ 2>$ERR_FILE

# Determine error and remove tmp file
ERROR=`cat $ERR_FILE`
rm $ERR_FILE

# Handle an error
if [ "" != "$ERROR" ]; then

        # Error occured
        if [ "Warning: Using a password on the command line interface can be insecure." != "$ERROR" ]; then
                echo $ERROR >&2
                exit 1
        fi
fi

t
tresf

For PowerShell (pwsh, not bash), this was quite a rube-goldberg solution... My first attempt was to wrap the calls to mysql in a try/catch function, but due to some strange behavior in PowerShell error handling, this wasn't viable.

The solution was to override the $ErrorActionPreference just long enough to combine and capture STDERR and STDOUT and parse for the word ERROR and re-throw as needed. The reason we couldn't catch and release on "^mysql.*Warning.*password" is because PowerShell handles and raises the error as one stream, so you must capture it all in order to filter and re-throw. :/

Function CallMySQL() {
    # Cache the error action preference
    $_temp = $ErrorActionPreference
    $ErrorActionPreference = "Continue"

    # Capture all output from mysql
    $output = (&mysql --user=foo --password=bar 2>&1)

    # Restore the error action preference
    $ErrorActionPreference = $_temp

    if ($output -match "ERROR") {
        throw $output
    } elseif($output) {
        "   Swallowing $output"
    } else {
        "   No output"
    }
}

Note: PowerShell is available for Unix, so this solution is cross-platform. It can be adapted to bash with some minor syntax modifications.

Warning: There are dozens of edge-cases where this won't work such as non-english error messages or statements that return the word ERROR anywhere in the output, but it was enough to swallow the warning for a basic call to mysql without bombing out the entire script. Hopefully others find this useful.

It would be nice if mysql simply added an option to suppress this warning.


P
Patrick.SE

If you happen to use Rundeck for scheduling your tasks, or any other platform where you ask for a mylogin.cnf file, I have successfully used the following shell code to provide a new location for the file before proceeding with sql calls:

if test -f "$CUSTOM_MY_LOGINS_FILE_PATH"; then
   chmod 600 $CUSTOM_MY_LOGINS_FILE_PATH
   export MYSQL_TEST_LOGIN_FILE="$CUSTOM_MY_LOGINS_FILE_PATH"
fi

...

result=$(mysql --login-path=production -NBA -D $schema -e "$query")

Where MYSQL_TEST_LOGIN_FILE is an environment variable that can be set to a different file path than the default one.

This is especially useful if you are running in a forked process and can't move or copy files to the $HOME directory.

See documentation here.


W
WiR3D

The problem I had was using the output in a conditional in a bash script.

This is not elegant, but in a docker env this should really not matter. Basically all this does is ignore the output that isn't on the last line. You can do similar with awk, and change to return all but the first line etc.

This only returns the Last line

mysql -u db_user -pInsecurePassword my_database ... | sed -e '$!d'

It won't suppress the error, but it will make sure you can use the output of a query in a bash script.


N
Neil Davis

the best solution is to use alias:

alias [yourapp]-mysql="mysql -u root -psomepassword -P3306 -h 127.0.0.1"

example, put this in your script:

alias drupal-mysql="mysql -u root -psomepassword -P3306 -h 127.0.0.1"

then later in your script to load a database:

drupal-mysql database_name < database_dump.sql

to run a statement:

drupal-mysql -e "EXEC SOMESTATEMENT;"

then unalias the aliaas:
FYI you can't use alias if you are calling mysql inside a function inside the script.
An alias doesn't hide warnings and also now I can just type "alias" in your console and see your password...
l
ltning

The answer from @david-g is quite excellent, but at least BSD grep will interpret the [Warning] as a regular expression representation of a single character (matching any one of the characters in the word Warning).

For my scripts, I'm using the same approach, wrapped in a function (and only matching parts of the string, for simplicity):

mysql() {
  (
    (
      (
        (
          (
            /usr/local/bin/mysql "$@"
          ) 1>&9
        ) 2>&1
      ) | grep -v 'Using a password on the command line interface can be insecure.'
    ) 1>&2
  ) 9>&1
}

out=$(mysql ...... 2>&1)
rc=$?

The above will call mysql with a set of options, redirect the filtered stderr to stdout, and capture the combined output in $opt and the exit code in $rc.


B
Benoit Duffez

Another solution (from a script, for example):

 sed -i'' -e "s/password=.*\$/password=$pass/g" ~/.my.cnf
 mysql -h $host -u $user $db_name -e "$sql_cmd"

The -i'' option is here for compatibility with Mac OS X. Standard UNIX OSes can use straight -i


password is still on command line of the 'sed' so remains visible in process listings, even if only briefly.
M
Mr. Pyramid

It worked for me- Just added 2> null after the $(mysql_command), and it will suppress the Errors and Warning messages only.


That also means you don't get a report when something else goes wrong!
Also, you probably wanted 2>/dev/null. Using 2> null would just put output into a file called "null" in current directory.
S
Stan Khalipa

You can execute mySQL and suppress warning and error messages by using /dev/null for example:

# if you run just a SQL-command
mysql -u ${USERNAME} -p${PASSWORD} -h ${HOST} ${DATABASE} -e "${STATEMENT}" &> /dev/null

# Or you can run SQL-script as a file
mysql -u ${USERNAME} -p${PASSWORD} -h ${HOST} ${DATABASE} < ${FILEPATH} &> /dev/null

Where:

${USERNAME} - existing mysql user

${PASSWORD} - password

${HOST}     - ip or hostname, for example 'localhost'

${DATABASE} - name of database

${STATEMENT}- SQL command

${FILEPATH} - Path to the SQL-script

enjoy!


Just be aware that it will suppress ALL error messages, not just those password warnings.
R
RobC

The easiest way:

mysql -u root -p YOUR_DATABASE

Enter this and you'll need to type your password in.

Note: Yes, without a semicolon.


This works if you're at the console. I don't want to be at the console if I'm running a dump once a day...