I'm setting up a lamp server on my android phone, and i didn't managed to get mysql working with the default settings. i had to change the user to root in the my.cnf.
So i'm curious about the dangers of running mysql under the root user.
running MySQL as root, means everything the server does is also done as root (obvious). Especially if you happen to make a mistake, this can cause problems:
if you mis configure the mysql logfile to /etc/passwd, then that important file will probably be overwritten (a normal user cant do that).
root usually as some amount of disk system reserved (per filesystem), thus you can easier make the partition full as root.
code injection: if you have scripts running (for backup of the now root owned files) than you need higher privileges there, and again any mistake might have a bigger impact.
It is ok to login as a root user. However, use it to create new users with limited privileges on objects (tables, indexes, databases, etc) so that those users can't break anything other than what they're allowed to :)
Once the new users are created logout as root and login with those new users. I see you're using linux, so the idea of root user applies to MySQL in a similar way as in linux.
You can check the official documentation about this: Adding users and granting privileges
Related
For the past few days, I've been working with an OpenCart installation — v1.5.6.4 — that uses MySQL's root user. So far, I've not noticed any oddities nor errors.
However, the 4th point of OpenCart's install.txt states:
Make sure you have installed a MySQL Database which has a user assigned to it DO NOT USE YOUR ROOT USERNAME AND ROOT PASSWORD
Why does the readme file explicit the non-usage of MySQL's root user?
What errors will there be when OpenCart is set up with MySQL's root user?
There won't be any errors but it's strongly advisable to not use the root user unless you absolutely have to. This is for security reasons. Set up a DB user that has just enough permissions to allow OpenCart to work and use that user instead.
This is advisable for any system, not just OpenCart. They're just giving you some security advice.
I recently installed the XAMPP stack on a desktop and connected via a laptop on the local network. To my surprise, I was able to access phpmyadmin and delete update all mysql tables. Though I understand that I shouldn't use xampp for production (and I'm not), I would still like to learn how to manage these types of obvious security flaws. I know that I can block access to directories via .htacces (http://forum.directadmin.com/showthread.php?t=29089), but I would like something that is a little more comprehensive. How would you restrict running of mysql queries from anywhere except localhost? Is there a way without .htaccess? I thought this was partially the purpose of the root user.
MySQL defined users with domains. If you look at your user_privileges table in the information_schema database you will see that they all have domains. If all your users are defined strictly as localhost, there will be no remote access.
Also, you can edit my.cnf to turn off tcp access to the database, forcing all connections to be by socket. under [mysqld], include the line skip-networking. You will have to configure all your apps to use the socket connection, but I like the socket better anyway.
This will do nothing to protect your data from someone using phpMyAdmin, if phpMyAdmin is installed on the same machine as the database. The safest thing to do is get rid of that app. That's often not practical, however, as it's a useful tool, and so you need to configure phpMyAdmin to require that users authenticate themselves. That means NOT putting the password in the config file. You will need to think about how long sessions are before reauthentication, and things like that.
phpMyAdmin fills me with a rage hotter than a thousand suns whenever I try to configure it, but it is definitely possible to set things up so a password is required each time you connect to the database through phpMyAdmin. You can further limit the damage phpMyAdmin abusers can do my making sure it only connects as a user with limited privileges (for instance, only able to modify the database you're working on at the moment).
If I have ensured that connections to the MySQL db are not using the root user account. I have created application specific users with appropriate schema privileges. I am just a little leery that I may be overlooking some system level function that uses the root user.
You should leave a root account - actually I am not sure you can remove it completely anyhow without some consequences. I am not sure, but I think it is needed for the password recovery, if all admin passwords are lost - you can start MySQL deamon (or service) with password free mode using special syntax. So basically, whoever has sudo access to your server can always access/alter all MySQL data.
But you should DEFINITELY define a password for the root and store it safe - not on the server, not even obscure, and possibly limit it to be able to connect only from localhost.
By default, this is the case, root user cannot connect from any host but localhost, so don't change that.
You should change the name of the default MySQL root user. I usually do that on all my MySQL installations.
GRANT SELECT ON source_starcraft.udb_ability TO `wade`#`localhost'
When I login with wade via PHPMyAdmin I can't see the database source_starcraft. I've only executed this query and created the user prior to this query.
Here something that helped me a lot. Actually I was working with MySQL Workbench.
http://bobfield.blogspot.it/2006/10/i-cant-see-my-databases.html
Briefly, it says that if MySQL has an <anonymous> account, and you fail logging in with your user, you end up logged in as the anonymous user, without notice. To find out this you can do:
SELECT user(), current_user();
Here's why:
One important thing to note is that SELECT USER(); shows you your
current username and host. Another command, SELECT CURRENT_USER();
shows what you're authenticated as.
Indeed, in my case, user() was mylogin#localhost, current_user() was #localhost (the anon user).
If the user you logged into phpMyAdmin with does have the correct permissions to view the database, but you still can't see it, it might mean phpMyAdmin itself has been configured to not show it. This is easiest to verify by issuing a show databases; SQL query from within phpMyAdmin. If the database you are looking for shows up, the user is permitted to view it, at the least.
There are several config directives which can controls which databases are visible in phpMyAdmin's lists. If you used an automated installer or script to add phpMyAdmin to a user account, it might also have set one of only_db or hide_db. These are also described in the official phpMyAdmin documentation, which should have been included with your installation, and on the wiki.
If your user has access to change the settings, you can do it for the current session from within phpMyAdmin under "Settings" and the "Features" tab. To permanently change these settings you will need to edit config.inc.php. Its location depends on where phpMyAdmin is installed on your system.
Seems like there might me some conflict/confusion with respect to which host the permission was granted to, and which one(s) are being used.
After FLUSH PRIVILEGES to remove that possibility, I'd see which user I was being identified as once I was logged in:
SELECT user();
Note that MySQL always associates a login with the most specific host. See doc. Then compare that to what's in the privileges database.
SELECT * FROM mysql.user WHERE user='wade';
SELECT * FROM mysql.db WHERE user='wade';
To resolve the situation, either REVOKE or DELETE+FLUSH PRIVILEGES the trouble-causing conflict (being careful not to paint yourself into a corner), or GRANT more privileges to the one your user is identified as.
I had the same issue yesterday. I swap my data files HD onto another MySQL server (Same version of everything, replica brand new install same passwords as preventive maintenance). Had both root access, but I guess they are different machines and hashs for the passwords created at MySQL startup. When I listed for files, all are intact in both servers, but phpmyadmin could't see databases (just information_schema), even not available using MySQL thru shell, but files are at the right location.
When check ownership of files they where not owned by root, the owner was 'nobody', so I proceded to take ownership of the databases files at MySQL default data location using chown root:root *
So if you think that just replacing the data by swapping HDs, and beeing root in both places, with root access on both you will be happy camper. But not so quickly, you may need to check persmission and ownership of those files still to be able to list them in PHPMYADMIN
After that procedure, everything worked OK after reboot.
I've inherited development for a website on vps hosting, and have login info for a user with sudo privileges, but don't have the password for the mysql root user. After digging around a little, it looks like the only way to fix this is to stop mysql (something like this: http://waoewaoe.wordpress.com/2010/02/03/recover-reset-mysql-root-password/). But because the website it's serving is currently in production, I'm hoping you guys can enlighten me to any potential consequences (or let me know if there's typically a file where the password would be accessible).
a) during the time mysql is stopped, information in the database won't be accessible, right -- even by other users?
b) will resetting the root password have any impact on other users after mysql has restarted? Will their username/passwords still be valid? The current application is using an account with limited privileges to read/write to the database, and while 5min downtime in the middle of the night would probably go unnoticed, half a day while I tie up loose ends/figure out what I screwed up will land in me hot water.
Thanks in advance for your help!
You can look after back-up scripts and cron jobs. Maybe some script does a dump using the root account. If this is the case the password needs to be stored in cleartext. You can also look at configuration files of application that use the database.
You also need to be lucky. If you are not, you have to stop mysql, change the password and start it again.