0

This question is related to another question I subsequently asked here: Using the output from mysqldiff.exe to transform database2 to match database1.

I have been trying to use mysqldiff.exe, part of MySQL Utilities group of tools. The idea is to identify schema differences between two databases, or other contained objects (tables, routines, triggers, etc).

Basically this command:

mysqldiff.exe --server1=root:password@localhost:3306 
--server2=root:password@localhost:3306 db1:db2

seems to work, though I'm yet to fully grasp how to use this program's output for the purpose of transforming the one db to match the other! I guess I might have to ask that question differently further down the line.

My immediate issue is:

This utility screams: # WARNING: Using a password on the command line interface can be insecure., yet I am unable to find a means to avoid spilling out my passwords out there! There is no such option from the available help.

With regular MySQL binaries (mysqld.exe, mysql, mysqladmin, etc), I am able to use --login-path=xxxx, having configured the credentials using mysql_config_editor.exe. With Mysql Utilities, how can I solve this issue?

PS: I realize that my question's tags are a bit imprecise, but I stuff like "mysql-utilities" and "mysqldiff" are not available!

1

You can put the password in the my.cnf (or my.ini for Windows) and then login without specifying the password "over the wire". Obviously you want to keep that file secure, but in any decent setup, this should not be a problem.

LOGGING IN

[pol@localhost inst]$ ./bin/mysql --defaults-file=./my.cnf -S ./mysql.sock -u root  -- **NOTE: no password is needed here.**
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 2
Server version: 5.6.22-log Source distribution

Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> 

CONTENTS OF MY.INI OR MY.CNF

[client]
port        = 3306
socket      = /home/pol/Downloads/software/mysql/5.6/inst/mysqld.sock
host            = 127.0.0.1
user        = pol 
password    = dba   --  **<<-----NOTE password in client section**

PASSWORD NOT VISIBLE

mysql> \! ps -ef |  grep mysql
pol       2173  2122  0 Apr19 pts/0    00:00:19 ./bin/mysqld --defaults-file=./my.cnf
pol       9294  2197  0 00:09 pts/1    00:00:00 ./bin/mysql --defaults-file=./my.cnf -S ./mysql.sock -u root   **NOTE - no password visible "over the wire"
pol       9360  9294  0 00:16 pts/1    00:00:00 sh -c  ps -ef |  grep mysql
pol       9362  9360  0 00:16 pts/1    00:00:00 grep mysql
  • Ah! But to place my root credentials right in the plain-text configuration file! Dunno which is worse, this or on the command line! So, I take it then that the kind of functionality provided by mysql_config_editor is not available here? – Ifedi Okonkwo Apr 20 '15 at 7:44
  • 1
    But the point is that you should have your my.ini/my.cnf secure - the thing about this arrangment is that the password isn't visible to anyone who tries to run a ps | grep mysql. Although, I did test this in 5.6 and it hides the password even with a password passed on the command line. I would suggest that if you have hackers running around your system able to read sensitive configuration files, you have major problems. If logging in to another machine, use SSL. – Vérace Apr 20 '15 at 12:58
  • Consider this setup: Locally installed mysql server, running on an LAN network and supporting an intranet company application. Potentially careless IT staff supervising the server machine and its OS. Any of them can do "administrator" stuff on the system. Not really offsite hackers as such. – Ifedi Okonkwo Apr 20 '15 at 20:49
  • 1
    I assume that you keep your server room locked if this is an important business application? Most damage to systems (despite scare headlines about hackers from <insert country of your choice here> comes from disgruntled employees. Restrict access to this room to trusted employees - plus keep privileges to a minimum. IT security 101. You should only need to use root/admin rarely anyway. – Vérace Apr 20 '15 at 21:30
  • 1
    Well, you should inform your client of all relevant risks. All I can advise is that you audit all of your users - you mightn't be able to stop it, but at least you can find out after the fact. There are free ones available (haven't used). You should grant minimum privileges to all your users. Another CRITICAL thing, give one person responsibility and accountability for security in your company and on the client side. Establish best practices and make sure they're complied with. If your client's data/app is valuable, then they will have to take the necessary precautions/steps. – Vérace Apr 21 '15 at 17:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.