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.
Related
I would like to know if it is possible to block the possibility of changing the root password on a mariadb. I have to distribute software with a mariadb database, and I don't want users to be able to access the database in any way (only through the application), so it must not be possible to change the root password. Is it possible? Thank you
No, it is not possible to lock mariadb down. All you would have to do is stop the mariadb service, restart it using --skip-grant-tables option and you can reset the root password.
Furthermore, users may have legitimate reasons accessing the database (backup, migration, password rotation, changing password after a breach), so locking them out is not a great idea. However, if they tamper with the database, all responsibility should rest with them.
MariaDB does not provide a way to deny a user access to their own password.
To prevent passwords from being changed, the mysql/global_priv (since 10.4.1, for older versions mysql/user) file in your data directory should be set to read-only.
This also means that no new users can be created.
MariaDB [(none)]> create user foo#localhost;
ERROR 1036 (HY000): Table 'global_priv' is read only
I am searching for the best solution of the following:
I need to give somebody access to one (out of many) specific database on my MySQL server through PhpMyAdmin or a similar tool.
I am not allowed to create a new MySQL user account.
Therefore I am thinking of creating a cover-up username and password (the credentials might be stored in some table or even directly in PHP somewhere around PMA), with which my somebody would log in to PMA.
PMA would use a securely stored real username and password to connect to my MySQL server. But my somebody would never see the actual database username and password. He would only see and be able to edit tables within the one specified database on my server.
Is this somehow achievable? Thank you!
PMA has a configuration for this.
$cfg['Servers'][$i]['only_db']
Read about it in the documentation: https://docs.phpmyadmin.net/en/latest/config.html
But this does not restrict the privileges of the user. It only makes the user interface show a limited subset of databases to the user. If they know the name of some other databases (or can query them from INFORMATION_SCHEMA.SCHEMATA), they can still access those databases.
If you want to enforce privileges to only a few databases, you'll have to create a distinct MySQL user and limit their privileges with GRANT.
Re your comments:
It sounds like you need to store the MySQL credentials in your PMA config file (and set $cfg['Servers'][$i]['auth_type'] to 'config'). Then you can use Apache HTTP authentication to restrict access to your PMA site (or directory), and you can create multiple user credentials at the Apache level.
phpMyAdmin is not designed to work like this; it uses the MySQL authentication structure without imposing any additional login restrictions.
One part of your requirements (not sharing the actual username and password) might be solved by using the config or signon authentication method, but that still doesn't impose any additional restrictions on the user once they log in so they'd have the same access that your user account has.
Unfortunately for you, if you aren't able to create another user account it's going to be difficult to share the account without giving them the same level of access.
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.
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
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.