Some notes:

• The laptop I’m using had MySQL 5.1.55 installed with one database (apart from the system database). Installing MariaDB does not impact existing data in any way and once the install completed I had instant access to my data.
• As part of the install you are given the option to set a new password for the root user. I choose to do it in the video, but you don’t need to. If you leave the password field blank the root password will not be changed. Other database users are preserved, of course.
• As with any database upgrade, before doing this to a production system you should have backups and test.

Links:

Links shown or mentioned in the video:

• http://kb.askmonty.org/en/installing-mariadb-deb-files
• http://downloads.askmonty.org/mariadb/
• http://downloads.askmonty.org/mariadb/repositories/
• and of course: http://mariadb.org/

Comments?

What do you think? Should we make more screencasts? If so, what would you like to see demonstrated?

As part of the MySQL community, CPU’s are new to us — they are released on the Tuesday closest to the 17th day of January, April, July and October. This kind of reminds us of Patch Tuesday, but let’s not digress.

This is the first time MySQL is part of the Critical Patch Update, and the advisory suggests that there are 27 new security fixes for Oracle MySQL, with one of the vulnerabilities having the possibility of remote exploitation without authentication. As developers of a MySQL branch we are naturally concerned towards the nature of these CPU’s.

For starters, it’s good to note that MariaDB is always based from a branch of MySQL (MySQL 5.1 for MariaDB 5.1, 5.2 & 5.3, and MySQL 5.5 for MariaDB 5.5). So whenever there are security fixes which Oracle makes into MySQL 5.1 or MySQL 5.5, we inherit them. This is one of the benefits of being a branch as opposed to being a fork.

“Oracle advisories include all issues that appeared since the last advisory. But this is the first advisory for MySQL. So either Oracle found 27 new problems since October 2011 or this includes everything that’s been outstanding,” said Sergei Golubchik, VP of Architecture for MariaDB and former MySQL security contact when I asked him about the 27 security fixes.

Upon looking up all the CVE numbers, the reports were vague, like “Unspecified vulnerability in the MySQL Server component in Oracle MySQL 5.1.x and 5.5.x allows remote attackers to affect availability via unknown vectors.” Additionally, the reports do not reference bug numbers, so from a bit of guesswork, we might assume that this commit is possibly the fix for the most serious vulnerability — the one that can be remotely exploited without authentication. That bug, incidentally, was fixed in May 2011, and has long been present in both MySQL and MariaDB (though our implementation varies from upstream).

We notice most CVEs being reported in January 2012, but have no idea when they were reported to the Oracle bug database (or to bugs.mysql.com), or when they were fixed. We believe that this is perhaps Oracle including MySQL into their Software Security Assurance program, which is what triggered all security bugs to be reported on cve.mitre.org, all on the same day.

Whether these 27 fixes are new or existing ones now being bundled up and reported in a Critical Patch Update remains open until more accurate information on what bugs they address is provided. We’re actively working on finding out the answer.

Let’s suppose you have your data in MariaDB, installed, say, on Ubuntu. And your users connect to it to run ad hoc queries, using some sort of a Windows GUI client. You don’t want them to write the access password on post-it notes or have it auto-entered by the client. And you don’t want anyone see the password when one of the salespersons connects to the mother ship from his laptop in the Internet café. So you decide to use the two-step verification, just like Google does, to secure the access to the data.

If you don’t know what a “two-step verification” is, see, for example, this introductory video by Google.

So, 2-step verification looks great, but how can we implement it? Luckily, there is a PAM module in the Google Authenticator project, and we can use it with a MariaDB PAM authentication plugin.

Let me digress for a second. Below we will implement a 2-step verification based on Google Authenticator. But you may want to evaluate other similar solutions before putting this primer in production. There are quite a few PAM modules implementing one-time password approach (and pam_google_authenticator is just one of them). In particular, OPIE (and S/Key) look interesting, because they don’t require a valid Unix account and a home directory for every user. There are also hardware based solutions, where a user is required to have a small password generating device (like, for example, RSA SecurID).

But back to Google Authenticator. First, we need to install the PAM module. On Ubuntu 11.10 it is very simple: one apt-get. On distributions that don’t include it (and older Ubuntu versions), you can use manual installation instructions.

Either way, we install /lib/security/pam_google_authenticator.so (I don’t have Ubuntu 11.10, so I had to do it manually). For a 2-step verification we need to require both the normal account password and the one-time code. This can be achieved with the following PAM configuration file:

auth            required        pam_unix.so
auth            required        pam_google_authenticator.so
account         required        pam_unix.so

I had to put it in /etc/pam.d/mysql file, on your system the location may be different. Having done that, let’s install the MariaDB PAM plugin and create the user account:

Now we need to configure Google Authenticator for an account:

Time to install a password generator application. There are versions for Android, iOS, and Blackberry. Google explains the details. When the installation is finished, start the application and enter the secret key into it — manually or using the QR-code. And we’re done and can use two-step verification when connecting to MariaDB. But our users use Windows! How will it play along?

The answer depends on the Windows MariaDB client that that your users have. At the moment of writing this article, only HeidiSQL has full support for pluggable authentication. You may already have it installed — HeidiSQL is part of MariaDB Windows distribution. Alternatively, you can download it directly from the official site.

First, we use HeidiSQL session manager to configure the connection parameters. Here, we will connect as the user “serg” — the  user, that we have created above to use the PAM authentication plugin. Note that there is no special configuration for pluggable authentication on the client, it is enabled automatically when necessary.

Now we can connect to the server. It uses PAM authentication plugin, that loads Google Authenticator, that asks for a verification code. And we see HeidiSQL asking:

We start the Authenticator application, it generates the verification code:

And we use it to login! Next time the verification code will be different, and nobody looking over the shoulder will be able to steal our precious connection password.

This year culminated in MariaDB 5.3.3, the release candidate of 5.3. This is a significant release that makes years of work available by default in the database server. Earlier releases still required features to be explicitly switched on, but thanks to thorough testing assuring the quality of the new functionality we have now enabled them. It’s still called a release candidate which means it’s ready for general usage, but we want more user feedback before calling it stable. Make yourself familiar with the MariaDB 5.3.3 release notes.

Most of the new features and functionality of 5.3.3 are performance related making it possible to suddenly e.g. make use of subqueries, which previously has been a rare sight in MySQL® based applications due to the limitations that has existed. This is now addressed in MariaDB and we encourage you to start using subqueries. You will actually get a result to your query in a reasonable time.

Another nice addition in 5.3.3 is the new GIS (Geographic Information System) functionality. MariaDB introduces spatial functionality in accordance with the OpenGIS specification. If you have the need for GIS functionality in your application try MariaDB.

We had some challenges with the packaging of the authentication plugins and our release schedule was affected. Watch out for MariaDB 5.2.11 and MariaDB 5.5 in early 2012.

During 2011 we saw a huge increase in MariaDB popularity. We saw MariaDB being selected as the database for really critical systems (stay tuned for case studies of some of these systems). We saw some of the biggest IT companies making initial bets on MariaDB. A better basis for MariaDB’s 2012 couldn’t exist!

Thank You and Happy Holidays!

We’re happy to announce the following:

• The next version of MariaDB, version 5.2.10 will include an open source PAM Authentication Plugin. MariaDB 5.2.10 is scheduled for release next week.
• A Windows Authentication Plugin is in development and QA currently and will be part of MariaDB 5.2.11, which is scheduled for release before Christmas.
• MariaDB 5.5 will include both of the above plugins and an open source thread pool implementation. The soon-to-be-launched first version however will not include the thread pool.

Stay tuned for more information as soon as we start launching the above features.

Mission critical services relying on MariaDB should be aware that SkySQL has familiarized themselves with the new features and are ready to support all of the above options.

Also, as you might have heard, Oracle has recently released a PAM authentication plugin for MySQL. Alas, this plugin will not run on MariaDB — although the MySQL implementation of pluggable authentication is based on ours, the API is incompatible. And, being closed source, this plugin cannot be fixed to run in MariaDB. And — I’m not making it up — this plugin does not support communication between the client and the server, so even with this plugin and all the power of PAM the only possible authentication method remains a simple username/password combination.

But writing authentication plugins is easy, I said to myself. I will do my own authentication plugin! With blackjack and hookers.

I started by installing the development headers:

$ sudo rpm -ivh MariaDB-devel-5.2.9-102.el5.x86_64.rpm

On Debian or Ubuntu you would’ve needed to install libmariadbclient-dev. By the way, a disclaimer — I’m doing it for MariaDB-5.2, but with minimal changes this plugin can work with MySQL-5.5 too.

Now I create a working directory and, being a lazy guy, copy the auth_socket plugin  sources — one of the authentication plugins that come with MariaDB — from Launchpad (only auth_socket.c). Stripped down, with the old code removed, it becomes my pam.c:

#define MYSQL_DYNAMIC_PLUGIN
#include <mysql/plugin_auth.h>

static int pam_auth(MYSQL_PLUGIN_VIO *vio, MYSQL_SERVER_AUTH_INFO *info)
{
}

static struct st_mysql_auth pam_info =
{
  MYSQL_AUTHENTICATION_INTERFACE_VERSION,
  "dialog",
  pam_auth
};

mysql_declare_plugin(pam)
{
  MYSQL_AUTHENTICATION_PLUGIN,
  &pam_info,
  "pam",
  "Sergei Golubchik",
  "PAM based authentication",
  PLUGIN_LICENSE_GPL,
  NULL,
  NULL,
  0x0100,
  NULL,
  NULL,
  NULL
}
mysql_declare_plugin_end;

At the end of the file we have the plugin descriptor — it always has the same structure for all plugin types. Above it — authentication plugin descriptor, it tells MariaDB which function performs the actual authentication, and what plugin the client should use.

Let me repeat — what plugin the client should use. Indeed, an authentication process is always a dialog. The server asks questions (“username?”, “password?”), the client answers them. Because a loadable plugin may cause the server to ask the most unexpected questions (“the fingerprint of the left index finger?”), the client should support plugins too — which know how to answer them. And it does support them — or, more precisely, libmysqlclient does, automatically and transparently for the client applications.

In this particular case, though, the questions aren’t very exotic. PAM may only ask the end user to enter some text, so the client plugin needs to be able to print prompt text, read the user’s input, and send it back to the server. And repeat until the server is satisfied. Luckily, MariaDB already has a plugin to perform such a dialog with the user. The plugin is called, not surprisingly, dialog, and in my plugin descriptor, I specify that the pam server plugin needs the client to load the dialog plugin to be able to continue the authentication.

Now, let’s see if this plugin skeleton works:

$ gcc -o pam.so pam.c `mysql_config --cflags` -shared -fPIC -lpam

It compiles and even loads into the server. Looks good so far, and I open man pam.

According to the man pages, to perform a PAM authentication one needs to do the following:

1. initialize the PAM subsystem with the pam_start() function.
2. invoke pam_authenticate() which performs the actual authentication
3. verify the user’s account with the pam_acct_mgmt()
4. in the process of authentication, PAM can change the user name. Retrieve the new name with pam_get_item(PAM_USER)
5. at the end one should always call pam_end()

To talk to the client, PAM allows one to specify a conversation function — the function that PAM will invoke as necessary.

I then put the above logic into the main pam_auth() function:

#include <string.h>
#include <security/pam_modules.h>
#include <security/pam_appl.h>

static int conv(int n, const struct pam_message **msg,
                struct pam_response **resp, void *data)
{
}

#define DO(X) if ((status = (X)) != PAM_SUCCESS) goto end

static int pam_auth(MYSQL_PLUGIN_VIO *vio, MYSQL_SERVER_AUTH_INFO *info)
{
  pam_handle_t *pamh = NULL;
  int status;
  const char *new_username;
  struct param param;
  struct pam_conv c = { &conv, &param };

  /* get the service name, as specified in

     CREATE USER ... IDENTIFIED WITH pam_auth AS  "service"

  */
  const char *service = info->auth_string ? info->auth_string : "mysql";

  param.ptr = param.buf + 1;
  param.vio = vio;

  DO( pam_start(service, info->user_name, &c, &pamh) );
  DO( pam_authenticate (pamh, 0) );
  DO( pam_acct_mgmt(pamh, 0) );
  DO( pam_get_item(pamh, PAM_USER, (const void**)&new_username) );

  if (new_username)
    strncpy(info->authenticated_as, new_username,
            sizeof(info->authenticated_as));

end:
  pam_end(pamh, status);
  return status == PAM_SUCCESS ? CR_OK : CR_ERROR;
}

The plugin is almost done. The only missing bit is the conversation function conv(). According to the PAM documentation, it will be invoked with an array of “questions”, which should be shown to the user, and it must return the user’s answers. Additionally, it will get one opaque pointer argument — callback functions almost always have it in almost all the APIs in the world. From this function I will send the “questions” to the client, and receive the answers. The dialog plugin on the client side will do the actual communication with the user.

Sending and receiving is easy in the Pluggable Authentication API. One of the arguments of the main authentication function — pam_auth() in our case — is a so called vio handle. This handle provides read_packet() and write_packet() functions, which the client and server plugins can use to communicate with each other. The server will take care of everything else — delivering packets, splitting and reassembling them, encrypting (if SSL is used), using unix sockets, tcp/ip, named pipes, shared memory, making sure that the server plugin talks to the right client plugin, maintaining backward compatible protocol on the wire, and so on. That’s, by the way, where the name vio comes from — it means Virtual I/O.

There is one last difficulty to overcome. PAM can send four different types of messages, two of them being purely informational, with the meaning “print this to the user”, and two being input messages, with the meaning “print this and read the reply”. The dialog plugin, however, supports only “print this and read the reply” kinds of actions. To solve this API mismatch, our conversation function will accumulate PAM informational messages until it sees the first input message. Then it’ll send all accumulated and concatenated messages to the dialog plugin as one big prompt string, in one packet. This is what I mean:

struct param {
  unsigned char buf[10240], *ptr;
  MYSQL_PLUGIN_VIO *vio;
};

static int conv(int n, const struct pam_message **msg,
                struct pam_response **resp, void *data)
{
  struct param *param = (struct param *)data;
  unsigned char *end = param->buf + sizeof(param->buf) - 1;
  int i;

  for (i = 0; i < n; i++) {
    /* if there's a message - append it to the buffer */
    if (msg[i]->msg) {
      int len = strlen(msg[i]->msg);
      if (len > end - param->ptr)
        len = end - param->ptr;
      memcpy(param->ptr, msg[i]->msg, len);
      param->ptr+= len;
      *(param->ptr)++ = 'n';
    }
    /* if the message style is *_PROMPT_*, meaning PAM asks a question,
       send the accumulated text to the client, read the reply */
    if (msg[i]->msg_style == PAM_PROMPT_ECHO_OFF ||
        msg[i]->msg_style == PAM_PROMPT_ECHO_ON) {
      int pkt_len;
      unsigned char *pkt;

      /* allocate the response array.
         freeing it is the responsibility of the caller */
      if (*resp == 0) {
        *resp = calloc(sizeof(struct pam_response), n);
        if (*resp == 0)
          return PAM_BUF_ERR;
      }

      /* dialog plugin interprets the first byte of the packet
         as the magic number.
           2 means "read the input with the echo enabled"
           4 means "password-like input, echo disabled"
         C'est la vie. */
      param->buf[0] = msg[i]->msg_style == PAM_PROMPT_ECHO_ON ? 2 : 4;
      if (param->vio->write_packet(param->vio, param->buf, param->ptr - param->buf - 1))
        return PAM_CONV_ERR;

      pkt_len = param->vio->read_packet(param->vio, &pkt);
      if (pkt_len < 0)
        return PAM_CONV_ERR;
      /* allocate and copy the reply to the response array */
      (*resp)[i].resp = strndup((char*)pkt, pkt_len);
      param->ptr = param->buf + 1;
    }
  }
  return PAM_SUCCESS;
}

That’s all. Now I can compile it as above (repeating the process twice, because I forgot -lpam the first time), load it, configure PAM to use pam_skey for the “mysql” service, create the user and, finally, login:

$ mysql -u root
Welcome to the MariaDB monitor. Commands end with ; or g.
Your MariaDB connection id is 1
Server version: 5.2.9-MariaDB-debug Source distribution

MariaDB []> CREATE USER serg IDENTIFIED VIA pam USING 'mysql';
Query OK, 0 rows affected (0.00 sec)

MariaDB []> ^DBye
$ mysql -u serg
challenge otp-md5 99 th91334
password: <Enter>
(turning echo on)
pasword: OMEN US HORN OMIT BACK AHOY
Welcome to the MariaDB monitor. Commands end with ; or g.
Your MariaDB connection id is 2
Server version: 5.2.9-MariaDB-debug Source distribution

MariaDB []> SELECT "Hey-ho! It works!!!";


(εφημερίδα = newspaper)

In addition I often use Launchpad aliases, such as lp:~maria-captains/maria/5.3-serg/, lp:maria/5.3, and lp:869001.

And finally, there are common abbreviations that we have used in MySQL, and others that we use in MariaDB, for example bug#12345 and wl#90.

What’s annoying, I need to remember that wl#90 corresponds to http://askmonty.org/worklog/?tid=90 and type the latter in the location bar of the browser, when I want to look this task up. And lp:869001 is, for my browser, https://bugs.launchpad.net/bugs/869001. Similarly, every other URL above, has its browser-friendly evil twin. It’s evil, because I have to remember it!

Now, Firefox tries to help, to a certain extent. It supports so-called keywords — short aliases for bookmarks. Create a bookmark for https://bugs.launchpad.net/bugs/%s and in the Keyword field enter lp. Now you can type in the location bar lp 869001 (with a space) and Firefox will expand it into a complete url https://bugs.launchpad.net/bugs/869001. Quite handy. And I’ve used it for a few years. Still it annoyed me, that I had to rewrite the abbreviations manually, put spaces, remove colons, and so on. And at last it annoyed me to a degree where I wrote a Firefox plugin!

Let me introduce a LocationMorph — a plugin that can arbitrarily rewrite the text in the location bar, according to the user specified regular expression. I have configured it (via a Preference dialog) to use the following set of rules

^bzr+ssh://bazaar.launchpad.net/	→	http://code.launchpad.net/
^lp:(d+)$	→	https://bugs.launchpad.net/bugs/$1
^lp:	→	http://code.launchpad.net/
^wl#(d+)$	→	http://askmonty.org/worklog/?tid=$1
^bug#(d+)$	→	http://bugs.mysql.com/bug.php?id=$1

And now I can simply copy and paste a bzr URI, or a launchpad alias, or our internal abbreviation from the email (or bzr info) directly into the browser, and it understands it directly and shows me the page that I want. Ahh, perfection…