|< Day Day Up >|
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:
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.
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.
|< Day Day Up >|