As you all know MariaDB supported roles since the MariaDB release 10.0.5. They were implemented almost exactly as specified in the SQL Standard 2003, features T331 “Basic roles” and T332 “Extended Roles”.

But we were often hearing complains, users were not satisfied with purely standard set of features. In particular, the standard specified that one had to do

to be able to use privileges, granted to the role foobar. This was not always convenient and sometimes not even possible (imagine, you need to grant role privileges to an account used by a closed-source application). There had to be some way to enable a given role automatically, when a user connects.

To solve this issue we have introduced the concept of a default role. A default role for given user is automatically enabled when this user connects. Problem solved!

To set foobar as a default role you use, quite logically,

This stores your default role in the mysq.user table, and next time you connect the role foobar will be enabled for you automatically.

To remove a default role use

this works similarly to the standard SET ROLE statement.

You can also set a default role for another user (remember that use case with a closed-source application?):

Privilege-wise, if you can enable a role (using SET ROLE statement), you can make it a default (using SET DEFAULT ROLE statement). But to change a default role for someone else, you need insert privilege for the mysq.user table — same as when you change a password for someone else.

And don’t forget to run mysql_upgrade before using default roles — as they are stored in privilege tables, these tables have to be updated to the latest version to include the necessary columns. Otherwise SET DEFAULT ROLE statement will fail.

The implementation for this feature was contributed by Vicenţiu Ciorbaru.

This is both hilarious and sad. The new MySQL 5.7 milestone release presents a new feature — replication filters are now dynamic. This is a great and long awaited feature, no doubt about it.

In short, for years MySQL slaves could filter the incoming stream of replication events based on the database or table name these events were applicable to. These filters were configured using the my.cnf file (or command-line), in particular with the following variables:

Naturally, users wanted to be able to change the values of these options without having to restart the server. And eventually Davi Arnaut implemented it. MariaDB got it as a contribution back in version 5.5.22. Since that release these options in MariaDB have been dynamic system variables and one could change them at will. For example,

Now, I understand that sometimes we might implement a certain useful feature first. And I understand that in that case Oracle might want to have it, while not looking like they’re following MariaDB. Of course not! The feature must be totally original. With completely incompatible syntax. Most recent examples would be EXPLAIN FOR CONNECTION in MySQL 5.7.2 about a year after SHOW EXPLAIN was introduced in MariaDB, and multi-source replication using “channels”, while MariaDB has already been using named slaves for quite a while.

But really, there should be some logic in it. Admittedly, EXPLAIN FOR CONNECTION isn’t worse than SHOW EXPLAIN. And multi-source “channels” look just fine, syntax-wise. Still, if there is a command-line option, there (almost always) is a corresponding system variable, visible in SHOW VARIABLES. One (almost always) changes the value of the option by assigning a new value to the corresponding variable. There is only one way of doing it.

Alas, we have taken this way in MariaDB. So, by strictly adhering to the NIH principle (and, I suspect, internal Oracle policies), MySQL developers simply had to invent a different way of changing server options. Lo and behold, CHANGE REPLICATION FILTER statement. Examples are:

Well done. Common sense? Nope, not in this case.

I’m getting more and more concerned about the current Oracle approach to MySQL security. And the fact that I was solely responsible for the security@mysql.com for about ten years, doesn’t make it easier, on the contrary, it only emphasizes changes in the attitude.

Starting from the obvious — somewhat slower response to critical bug fixes, which can be expected, Oracle is a big company, right? Very little information about security vulnerabilities is disclosed, CPUs are carefully stripped from anything that might help to understand the problem, it takes hours to map them to code changes. Heck, even test cases are kept private now. This seriously smells Security through Obscurity to me.

But all that isn’t news. Here I want to talk about the recent wave of security vulnerabilities. If you search for, say, “mysql security full-disclosure”, you will find the original postings to the full-disclosure@lists.grok.org.uk mailing list, as well as further discussion and my replies. Not Oracle replies, though. In short, the vulnerabilities  announced in the early December were:

  1. CVE-2012-5611 MySQL (Linux) Stack based buffer overrun PoC Zeroday
  2. CVE-2012-5612 MySQL (Linux) Heap Based Overrun PoC Zeroday
  3. CVE-2012-5613 MySQL (Linux) Database Privilege Elevation Zeroday
  4. CVE-2012-5614 MySQL Denial of Service Zeroday PoC
  5. CVE-2012-5615 MySQL Remote Preauth User Enumeration Zeroday
  6. CVE-2012-5627 MySQL Local/Remote FAST Account Password Cracking

All posted to the full disclosure mailing list, accompanied by exploits in Perl. Out of these issues, the 3rd was a configuration issue (FILE privilege granted to untrusted user, no --secure-file-priv used), 4th was already fixed in the latest MariaDB and MySQL releases (the reporter used an outdated MySQL version), 1st — the most dangerous one — was already fixed in the latest MariaDB release (we were lucky to discover this issue independently few weeks ealier and immediately released a fix). Everything else was valid, exploitable, and very much public, after the original postings were quoted in various blogs and news articles.

In a due time MySQL 5.5.29 is released. The 1st issue — CVE-2012-5611 — looks fixed. The second one — CVE-2012-5612 — is fixed too. Hurra! But 5th and 6th vulnerabilities — CVE-2012-5615 and CVE-2012-5627  — are not fixed. Which, apparently, leaves MySQL installations at the mercy of any script-kiddie, who can use google. And the 1st one (the worst of all) is fixed incompletely — the fact, that is simply impossible to miss, given the amount of testing that MySQL continuous integration framework (Pushbuild2) is performing.

Really, I wouldn’t expect a database vendor to blatantly ignore publicly announced vulnerabilities, that have CVE identifiers, known and easily available exploits, and were posted and reposted all over. So, Oracle, what was that, eh?

2013/Feb/05 UPDATE: MySQL 5.5.30 doesn’t seem to fix these issues either. Two months after the vulnerabilities went public. After MariaDB 5.5.29 release (with the fixes) and this blog post! I don’t think the Hanlon’s razor can explain that.