As I wrote in my last blog port, I’ve been enabling selinux on some webservers. Last week I updated the Idera CDP agent on one server to support backup and restore of MySQL via the CDP agent. The backup is successful without any issues. Since this integrated MySQL backup was new functionality, I also wanted to test the restore. The restore did not work with selinux enabled. There were a ton of error messages in the audit.log, actually too much to paste in this blog post. I’ve attached the file with error messages cdp-mysql.

To fix the problem I’ve created multiple selinux policies, after the first 4 tries new deny messages appeared in the audit.log. After the fifth version of the policy the restore finished without any error in the log and the database that I dropped and I tried to restore was available and accessible for the sites.

To create the working policy I did the following. I copied the messages that I attached into a separate file ( and used the following command to create a selinux policy:

audit2allow -i -M cdp-mysql

This creates a couple of files (cdp-mysql.pp and cdp-mysql.te) in the current working directory. The cdp-mysql.te contains the plain text policy. The cdp-mysql.pp file can be used to import the selinux policy:

semodule -i cdp-mysql.pp

This activates the cronolog selinux policy that contains the configuration listed below. After this module is activated cronolog is allowed to create directories under the log directory.

module cdp-mysql 1.0;

require {
type bin_t;
type fixed_disk_device_t;
type mysqld_t;
type port_t;
type var_lib_t;
class sock_file { create unlink getattr };
class tcp_socket name_bind;
class chr_file { read write };
class file { write getattr read lock open append };

#============= mysqld_t ==============
allow mysqld_t bin_t:file append;
allow mysqld_t fixed_disk_device_t:chr_file { read write };
#!!!! This avc can be allowed using the boolean 'allow_ypbind'

allow mysqld_t port_t:tcp_socket name_bind;
#!!!! The source type 'mysqld_t' can write to a 'file' of the following types:
# mysqld_db_t, hugetlbfs_t, mysqld_tmp_t, mysqld_log_t, mysqld_var_run_t, root_t

allow mysqld_t var_lib_t:file { read write getattr open lock };
allow mysqld_t var_lib_t:sock_file { create unlink getattr };

For those who want to use it I’ve attaced the cdp-mysql.pp module. Make sure to test the md5 checksum (44ec3ec35db17e0adab38ad0ba1fac10 cdp-mysql.pp). You can also recreate the module with the file containing the errors from the audit.log

Last week I was looking at testing SplashID Enterprise. While a first installation with the MySQL database running on a Mac Mini was working fine, the installation with the Splash Enterprise Admin client failed when the database was running on a default Linux (CentOS) installation. I tried contacting SplashData support, but they could not help me, so I tried to debug myself. I enabled the query log so I could see the queries executed by the Admin client. These queries showed that SplashID ran queries reffering to specific tables in upper case (eg. MYSQL.USER). I manually tried some of these queries and these queries failed with “unknown table” error.

Now I found the problem, I thought it was easy to fix it. I just had to make MySQL case-insensitive. This sounds easier than it actually was 🙂 Lots of articles talked about the character set and the collation, but these only affect the data in the tables, not the actual table name itself. Some googling let met to the lower_case_table_names setting in MySQL. It appears that Windows, Unix and MacOSX all have different default settings, and therefor behave differently.

Setting the following line in the my.cnf in the [mysqld] section solved my case problem with SplashID. MySQL now changes all table names to lower case.


Update: I have not tested SplashID Enterprise yet, so I don’t know if it is any good 🙂