I have an application which invokes the mysql client to run various tasks. For various reasons, mysql is invoked as the user who runs the application (this is central to the security model and would also affect functionality if changed). Currently the mysql username and password is passed to the client program via the command line - obviously this is not a desirable state of affairs.
Over-writing the $HOME/my.cnf file is not an ideal solution - there may be multiple, concurrent tasks running against different (local and/or remote) databases. The access to the databases must be authenticated.
Is there a way to pass a custom my.cnf file (or other way to securely pass the username and password) to the mysql client without having to simulate an interactive login?
(supplying a my.cnf file using --defaults-file or --defaults-extra-file results in mysql: unknown variable 'username=my_db_user'
You have tested this ?
$ cat .my.cnf
[client]
user=root
password=rootpw
$ mysql --defaults-file=/Pathtomycnf/.my.cnf
MariaDB [(none)]> quit
Bye
Related
Trying to use LOAD DATA LOCAL INFILE to import a csv file revealed the this command is not allowed with this MySQL version error.
So upon further reading I learn that SET GLOBAL --local-infile=1 can only be set if the mysql account is ROOT or setting it in the my.conf file (and restart mysql). For security purposes, my script that needs to import the CSV file is using a non-root mysql admin account. In fact all of my public facing scripts use a non-root admin account to open up mysql sessions. Thus with out a root account, it doesn't look like I can set it on the fly and then disable when the script is done.
Next option is to set it at the server level in my my.conf file and restart mysql. But once I enable --local-infile=1 on the server I have then exposed it to security issues. After that all a client needs to do mysql -u user -p password dbName --local-infile=1 for that session and then that client now has access. This def does not seem ideal...or am I wrong about this assumption?
The other option is then using LOAD DATA INFILE which apparently uses the root file systems /tmp directory to save files to and for mysql LOAD DATA INFILE to read from. But that then requires both the /tmp directory being globally available AND/OR a system admin having access to that directory. Unless I am root on the linux box, I can't write to that directory without opening it up globally. Opening up /tmp globally is itself a security issue.
Ideally, using a mysql non-root account, how can I enable --local-infile=1 temporarily to run my script and then disable it when done? Or...what is another method I can consider that would achieve the same result?
I am looking at automating a couple things when installing MySQL to a new host using a Chef server. These include:
mysqladmin -u root password {password_here}
mysql_secure_installation
I've created a .mylogin.cnf file with two login-paths, admin (which is root user), and mysqluser (non root user).
My issues are that I can't get (or understand how) .mylogin.cnf to create the DB users and password; and I can't automate the mysql_secure_installation using --defaults-file=.mylogin.cnf (assuming that's how the --defaults-file works) even though it's not specifying a login-path. Initially I was running the mysql queries via command line to harden the service, but was told that mysql_secure_installation uses --no-defaults, and --defaults-file to automate this particular task, but haven't found much online about those arguments.
Can anyone point me in the right direction?
The option --defaults-file is NOT used for setting/changing options in whichever tool you are running. This file is only used for specifying connection options (ie: host, username, socket, etc). For mysql_secure_installation specifically, you might try --use-default which, according to the manual, is used for unattended execution. In MySQL 5.7, a random root password is generated and printed in the error log. Simply grep this file for that password in your Chef script, then connect to MySQL and run whatever commands you need to create new users, dbs, etc. FYI, the generated root password is expired so when you connect, you have to change it first before you can do anything else.
When I start my MySQL client from the command-line, I do the following:
$ mysql -u root -p -h 127.0.0.1 --init-command="SET SESSION wait_timeout=300"
I set the session wait_timeout to 300 seconds for security purposes. If there is no database activity for 5 minutes, I want the connection to be killed so that it is not actively left open for long periods of time which is a security risk.
However, I really prefer using the Mac desktop application SequelPro to access the database instead of the command-line shell. It's my bread-and-butter. I absolutely love it. Here's what it looks like when I open a DB connection in SequelPro:
So how can I give SequelPro the same `--init-common argument I gave on the command-line above? Or is there any other way for me to achieve the security goal I'm trying for?
If you want to make this global setting for everyone connecting from any tool. You add this to the configuration file, my.cnf (if you're running MySQL on Unix-based OSs) or my.ini (if you're running MySQL on Windows-based OSs).
This is from MySQL documentation about wait_timeout
The number of seconds the server waits for activity on a
noninteractive connection before closing it.
On thread startup, the session wait_timeout value is initialized from
the global wait_timeout value or from the global interactive_timeout
value, depending on the type of client (as defined by the
CLIENT_INTERACTIVE connect option to mysql_real_connect()). See also
interactive_timeout.
So, set this global parameter in [mysqld] section of your configuration file to keep your security in check.
[mysqld]
interactive_timeout=300
wait_timeout=300
I start the mysql :
mysqld_safe --user=_mysql
and I create a file which blongs to root:
-rw-r--r-- 1 root staff 0 12 4 19:40 a
and exec:
mysql> system rm /home/test/a
and the file was deleted。
has anyone kown how to make 'system' command unavailable when the mysql account which is specified by 'mysqld -u' are different to the account of system(file or others)
The system command in the mysql client command line program doesn't run commands on the MySQL server machine. (If it did, can you imagine how easy it would be for cybercriminals to pwn IT infrastructure?)
It runs them on the same machine upon which you are running mysql.
The mysql command ordinarily runs with the same user and set of permissions as the shell program that invoked it. So, anything users could do with mysql system they could also do in the shell used to run it.
Therefore, disabling the mysql system command is unnecessary and insufficient for tightening system security.
(Users without shells are another story. If you have those kinds of users, you probably should disable the system command.)
If you don't trust the user who must run the mysql client you'll need to grant them a limited environment. You can look up chroot for that.
I'm trying to login to my mysql user created by the MySQL installation in bash shell.
So the command I'm trying to do is:
sudo -i -u mysql
But, it does nothing (nothing printed out in the console, not connected to any user whatsoever, etc...).
EDIT: The return value of the command is 1 though.
Here is the mysql user line in the /etc/passwd file:
mysql:x:89:89::/var/lib/mysql:/bin/false
I'm running on ArchLinux 64bit and the user I'm trying to connect to is local (no connection to a remote server whatsoever).
I'm trying to understand why I can login with any other user (like postgres, root, ...) but not mysql.
Hope you can help!
This is intended behaviour. When you compare the /etc/passwd line with other lines you'll notice that the user mysql has /bin/false setup as the shell while others have usually /bin/sh or sth. similar.
When you sudo to mysql you actually get a login for about a millisecond or so and then his "shell" gets executed. /bin/false immediately returns with rc=1 (that's the only purpose of the false command).
This is some kind of "trick" to prevent users from logging in as user mysql although the account is otherwise fully operational.
The user mysql may even have a valid password and be enabled but due to his odd shell setting you cannot login as him. Sometimes these technical users have /usr/bin/passwd set as their shell. Then you can only sudo to that user and change his password, nothing else.