Previous Section  < Day Day Up >  Next Section

10.7 MySQL in a chrooted Environment

Running a server in a chrooted environment greatly enhances overall system security on a Unix system. It does this by setting up an isolated environment in which files outside of a given directory are no longer accessible. That way, even if a security flaw is found in the server and exploited, the potential for damage is limited to the files in that directory, which should only be the files for that particular application.

The first thing to do is compile your MySQL from source. Many administrators already do this, but this is an absolute must in a chrooted application, because many prepackaged MySQL installations will put some files in /usr/bin, some in /var/lib/mysql, etc., and all the files in the chrooted installation need to reside under the same directory structure.

What we tend to do is to have a /chroot path where all chrooted applications live. Configure your MySQL installation using something like this:

$ ./configure --prefix=/chroot/mysql

Compile MySQL as you normally would, and let the installation procedure install the MySQL files in the /chroot/mysql tree.

The next thing to do is a little magic, to make everything happier. chroot actually stands for Change ROOT. If you enter:

chroot /chroot/mysql

the / directory is now actually /chroot/mysql. Because the MySQL files are used both by server (running chrooted) and client (which won't be), it's important to set up the filesystem so that both the server and the clients can find the files they need to. An easy solution to this problem is to do the following:

$ cd /chroot/mysql

$ mkdir chroot

$ cd chroot

$ ln -s /chroot/mysql mysql

This creates a symbolic directory path /chroot/mysql/chroot/mysql, which actually points to /chroot/mysql. Now, even if the application is chrooted and trying to get to /chroot/mysql, it will reach the proper directory. Meanwhile, if the client application is running outside the chroot environment, it can find the files it needs.

The last step is to send the proper commands to mysqld_safe, so that the MySQL server can start itself up and chroot to the proper directory. To do this, you might enter something like this:

$ mysqld_safe --chroot=/chroot/mysql --user=1001

You'll notice we used the Unix UID of the MySQL user, instead of --user=mysql. This is because in the chrooted environment, the MySQL server may no longer be able to query your authentication backend to do username-to-UID lookups.[14]

[14] From our experience in testing this, it might be as simple as copying libnss* to your MySQL library directory in the chrooted environment, but from a practical standpoint, it's probably best not to worry about such things, and just enter the UID directly in your startup script.

There are some caveats when using a chrooted MySQL server. LOAD DATA INFILE and other commands that directly access filenames may behave significantly differently than you expect because the server no longer considers / to be the filesystem root. So, if you tell it to load data from /tmp/filename, you should be sure that the file is actually /chroot/mysql/tmp/filename, or MySQL won't be able to find it.

    Previous Section  < Day Day Up >  Next Section