In local (not system-wide) installations, this will be the user, who installed MariaDB - she automatically gets convenient password-less root-like access, because, frankly, she can access all the data files anyway.Īnd even if MariaDB is installed system-wide, you may not want to run your database maintenance scripts as system root - now you can run them as system mysql user. This is why MariaDB creates a second all-powerful user with the same name as a system user that owns the data directory.
#MARIADB ROOT PASSWORD INSTALL#
Now, what happens, if you install MariaDB locally (for example, from a tarball)? You definitely would not want to use sudo to be able to login.
And still retain the password-less access via sudo!
#MARIADB ROOT PASSWORD PASSWORD#
By default it is disabled (“invalid” is not a valid password hash), but one can set the password with a usual SET PASSWORD statement. This is why in 10.4 the root user has a second authentication method - conventional MariaDB password. Still, some users complained that they want to log in as MariaDB root without using sudo. And if you want to script some tedious database work, there is no need to store the root password in plain text for the scipt to use (bye-bye debian-sys-maint user). But not asking for a password means, there is no root password to forget (bye-bye numerous tutorials “how to reset MariaDB root password”).
#MARIADB ROOT PASSWORD FULL#
It is based on a simple fact, that asking the system root for a password adds no extra security - root has full access to all the data files and all process memory anyway. This technique was pioneered by Otto Kekäläinen in MariaDB packages in Debian as early as MariaDB 10.0. Using unix_socket means that if you are the system root user, you can login as without a password. They are created as CREATE USER IDENTIFIED VIA unix_socket OR mysql_native_password USING 'invalid'ĬREATE USER IDENTIFIED VIA unix_socket OR mysql_native_password USING 'invalid' Technically, a new MariaDB installation will have two all-powerful accounts - root and the OS user that owns the data directory, typically mysql. And installation scripts will no longer shout at you “PLEASE REMEMBER TO SET A PASSWORD FOR THE MariaDB root USER !”, because the root account is created secure automatically. The open-for-everyone all-powerful root account is gone, at last. The default authentication for new installations is now more secure.
For example, a DBA might start migrating users to the more secure ed25519 password plugin, but keep the old SHA1 one as an alternative for the transitional period. One can specify more than one authentication method per account. If you happen to have tools that analyze er table - they should continue working as before. What happened to the er table? It still exists and has exactly the same set of columns as before, but it’s now a view over mysql.global_priv. All user accounts, passwords, and global privileges are now stored in a mysql.global_priv table. This post explains what has changed and what MariaDB Server is doing now. But if you have used MariaDB Server for a while, the new behavior might feel at times baffling. If you are a new user, you will hopefully find MariaDB Server easier and more intuitive to use with less struggling over passwords. And 10.4 brings changes to this process too. Some are MySQL compatibility features, requested by our users ( MDEV-7597, MDEV-13095).īut the first thing any MariaDB Server user, whether an experienced veteran or a newbie, does - before even issuing the first SQL statement - is logging in. Some of them are merely optimizations (like MDEV-15649), some improve existing features to be more robust ( MDEV-15473, MDEV-7598) or convenient ( MDEV-12835, MDEV-16266). MariaDB Server 10.4 came with a whole lot of Security related changes.
0 kommentar(er)
