Bad news: MySQL can dish out root access to cunning miscreants Security holes in MySQL can be abused to gain remote root access on poorly configured servers, it emerged on Monday. Patches to fix up the programming blunders were quietly released last week. The flaws are present in all default installations of MySQL 5.5, 5.6 and 5.7. Grab versions 5.5.52, 5.6.33 and 5.7.15 to avoid any …
> On the other hand why on earth does any part of MySQL run as root?
> I've used several other RDBMSs and no part of them runs as root.
For the same reason that everything else runs as root: if you want to listen on a "system" port (less than 1024) then you have to *start* as root. Not just MySQL: MariaDB, all your other RDBMSs, Apache. If you don't want to do this (and why would you?), then don't run mysqld_safe as root.
Apache normally listens on 80/443, so has to be started as root before it drops privileges. The docs have lots of useful advice on how to protect your system during this time, which cover exactly the issues in this article. The problem isn't that your attacker can load malicious code if they already have root access, it's that they can load malicious code when they're *not* root, which is the cunning plan.
Recent versions of MariaDB are diverging away very quickly from the MySQL/Percona/Facebook/WebScaleSQL pack.
As much as I dislike Oracle, I would stick with Percona or upstream (Oracle MySQL) for now.
Oracle to be fair has done some outstanding work with MySQL 5.6 and onwards, it just seems like it took a few years for it to be fully Borged.
How long it will take before it's fully Borked though!
It's worst than that. It's the Unix outdated permission systems with scripts run as root and software that must drop privileges itself because of lack of a more granular permission system on processes and files. Of course all the downvoters have no clue about a proper permission systems...
"Proper" fine-grained permissions systems like VMS ACLs are necessarily hard to use, and tend to get about as much use in practice, as a pay toilet in a forest.
At least the old Unix "me", "my group" and "everyone else" system does get used (most Linux distributions even put each user in their own group), and most of the time it even works reasonably well.
"It's the Unix outdated permission systems with scripts run as root and software that must drop privileges itself because of lack of a more granular permission system on processes and files."
No, it's developers* wanting to run their database engines with root permission when they shouldn't need to. There should be a $DatabaseEngine user and group. They can own the scripts, data and everything else to do with the engine. You're obviously unaware that such setups are not only practical but that they've been in use for decades.
"Of course all the downvoters have no clue about a proper permission systems."
No. We're the ones who actually do have a clue. And practical experience.
*Oracle have been around long enough to know better.
"No, it's developers* wanting to run their database engines with root permission when they shouldn't need to. "
Not only databases. For reasons no one can fathom , google seems to think its a good idea having the chrome sandbox process running as root on linux. No doubt they think their sandbox code is perfect and has zero security holes but anyone with a clue should install a different browser IMO.
I go one step further: every DB hosted on my DB server gets two partitions, several dedicated user accounts, and dedicated groups. The first partition stores the SQL daemon and configuration files and is mounter read-only. The second partition holds the actual db itself and is mounted within the first partition as read-write. As for users: The server daemon runs under its own process and is denied remote login to the server (its also assigned a null shell), multiple admin accounts are created for each db instance where each account is assigned to a specific physical person to admin that specific database, it has permissions to sudo as the server daemon.
Within the DB itself, two user accounts are created for every logical group of tables. One account has read-only access to the group of tables, the other has write. Every action by write group and queries by the read-only group that return far more than the expected amount of data, are logged into our monitoring and alerting tools. On top of that, everything is stored procedures. The security is set up like this so that even if someone where to discover the password for one of the SQL accounts (which are the only accounts that can connect to the DB servers from a non-IT subnet and only then can connect from the web boxen).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
