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
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.
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.
Suppose that I have a test server with a large group of test accounts. The test accounts have unknown passwords which are hard-coded into the application's reports and are stored encrypted in the mysql.users table.
Is there any option or hack which can be used to make mysql accept any text as the "correct" password for an account? For example:
Update mysql.user Set Password="*" where 1=1
Note: The above line wouldn't work because it would literally set the password to "*" and not the wildcard character. However, I am looking for a way to create a mysql account which would accept anything as a valid password. This machine is disconnected from the network and I have full access to the mysql database...
Not really.
What you can do:
change the password to a new one ( SET PASSWORD FOR Piskvor='hunter2'; FLUSH PRIVILEGES; )
restart the MySQL server with the --skip-grant-tables option. This will allow any password, for any connection, with access to any database. Caveat: this is a major security hole - any user can modify the mysql database, including the users and passwords while the server is running with this option.
(if you had full access to the database, but would not change existing passwords and/or could not modify server-process options, I'd suspect that something fishy was going on)
I don't think there is such a hack. However if the password is hardcoded somewhere it should be easy to extract them and generate a script. Except of course if the format where the password is stored is not readable.
Very old question. But today I have foundout that it can be done with --skip-grant-tables option on startup mysql service.
https://dev.mysql.com/doc/refman/5.7/en/server-options.html#option_mysqld_skip-grant-tables
--skip-grant-tables causes the server not to read the grant tables in the mysql system database, and thus to start without using the
privilege system at all. This gives anyone with access to the server
unrestricted access to all databases.