High Performance MySQL [Electronic resources] نسخه متنی

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.