Bug #12676 RHEL4: MySQL RPMs unusable when SELinux is enabled
Submitted: 19 Aug 2005 13:33 Modified: 3 Aug 2007 13:30
Reporter: Lenz Grimmer Email Updates:
Status: Not a Bug Impact on me:
None 
Category:MySQL Server: Installing Severity:S3 (Non-critical)
Version:4.1,5.0.40 OS:Linux (Red Hat Enterprise Linux 4, Fedora Core)
Assigned to: Daniel Fischer CPU Architecture:Any
Tags: bfsm_2006_11_02, bfsm_2007_03_01, install, redhat, rhel, rpm, selinux

[19 Aug 2005 13:33] Lenz Grimmer
Description:
RHEL4 comes with SELinux, which supports tighter access control for processes.
See http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ for more information about it.

When SELinux is enabled (SELINUX in /etc/selinux/config is set to "enforcing", SELINUXTYPE is set to either "targeted" or "strict"), the installation of the RHEL4 MySQL-server RPM fails - the server fails to start up after the RPM installation:

Starting MySQL...................................[FAILED]

A workaround is to disable SELinux by running "/usr/sbin/setenforce Permissive"

It seems like the postinstallation script that executes "mysql_install_db" to create the privilege tables is not executed properly, as the directory /var/lib/mysql is empty.

The syslog prints out the following:

Aug 19 15:10:51 rh-x86-32 kernel: audit(1124457051.253:0): avc:  denied  { search } for  pid=18714 exe=/usr/sbin/mysqld name=home dev=dm-0 ino=983041 scontext=root:system_r:mysqld_t tcontext=system_u:object_r:home_root_t tclass=dir
Aug 19 15:10:51 rh-x86-32 kernel: audit(1124457051.258:0): avc:  denied  { write } for  pid=18714 ex
e=/usr/sbin/mysqld name=mysql dev=dm-0 ino=1262940 scontext=root:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=dir
Aug 19 15:10:54 rh-x86-32 kernel: audit(1124457054.286:0): avc:  denied  { write } for  pid=18717 exe=/usr/sbin/mysqld name=mysql dev=dm-0 ino=1262941 scontext=root:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=dir
Aug 19 15:10:54 rh-x86-32 kernel: audit(1124457054.286:0): avc:  denied  { write } for  pid=18717 exe=/usr/sbin/mysqld name=mysql dev=dm-0 ino=1262941 scontext=root:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=dir
Aug 19 15:10:54 rh-x86-32 kernel: audit(1124457054.287:0): avc:  denied  { write } for  pid=18717 exe=/usr/sbin/mysqld name=mysql dev=dm-0 ino=1262941 scontext=root:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=dir
Aug 19 15:10:54 rh-x86-32 last message repeated 7 times
Aug 19 15:10:54 rh-x86-32 kernel: audit(1124457054.288:0): avc:  denied  { write } for  pid=18717 exe=/usr/sbin/mysqld name=mysql dev=dm-0 ino=1262941 scontext=root:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=dir
Aug 19 15:10:54 rh-x86-32 last message repeated 4 times
Aug 19 15:10:54 rh-x86-32 kernel: audit(1124457054.294:0): avc:  denied  { search } for  pid=18721 exe=/usr/sbin/mysqld name=home dev=dm-0 ino=983041 scontext=root:system_r:mysqld_t tcontext=system_u:object_r:home_root_t tclass=dir
Aug 19 15:10:54 rh-x86-32 kernel: audit(1124457054.299:0): avc:  denied  { write } for  pid=18721 exe=/usr/sbin/mysqld name=mysql dev=dm-0 ino=1262940 scontext=root:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=dir
Aug 19 15:10:54 rh-x86-32 kernel: audit(1124457054.378:0): avc:  denied  { append } for  pid=18752 exe=/usr/sbin/mysqld path=/var/lib/mysql/rh-x86-32.mysql.com.err dev=dm-0 ino=1262943 scontext=root:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=file
Aug 19 15:10:54 rh-x86-32 kernel: audit(1124457054.378:0): avc:  denied  { append } for  pid=18752 exe=/usr/sbin/mysqld path=/var/lib/mysql/rh-x86-32.mysql.com.err dev=dm-0 ino=1262943 scontext=root:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=file
Aug 19 15:10:54 rh-x86-32 kernel: audit(1124457054.380:0): avc:  denied  { search } for  pid=18752 exe=/usr/sbin/mysqld name=home dev=dm-0 ino=983041 scontext=root:system_r:mysqld_t tcontext=system_u:object_r:home_root_t tclass=dir
Aug 19 15:10:54 rh-x86-32 kernel: audit(1124457054.385:0): avc:  denied  { write } for  pid=18752 ex
e=/usr/sbin/mysqld name=mysql dev=dm-0 ino=1262940 scontext=root:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=dir
Aug 19 15:10:54 rh-x86-32 kernel: audit(1124457054.417:0): avc:  denied  { write } for  pid=18752 ex
e=/usr/sbin/mysqld name=mysql dev=dm-0 ino=1262940 scontext=root:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=dir

How to repeat:
To check if SELinux is enabled, run '/usr/sbin/selinuxenabled && echo "yes"'

Try to install the RHEL4 MySQL-server RPM on a RHEL4 system with SELinux enabled:

rpm -Uhv MySQL-server-standard-4.1.12-0.rhel4.i386.rpm

Notice the startup failure and check /var/log/messages for the audit errors.

Suggested fix:
The MySQL-server RPM would need to adapt the already existing "mysql" policy with one that matches the MySQL RPMs from MySQL AB.
[19 Aug 2005 13:36] Lenz Grimmer
BUG#12373 is probably related to the same problem, marking it as duplicate.
[19 Aug 2005 13:50] Lenz Grimmer
RHEL4 ships with a package "selinux-policy-targeted-sources" that already includes a policy for MySQL. However, these policies are designed for the MySQL RPM that ships with RHEL4, they don't exactly match the MySQL RPMs for RHEL4 from MySQL AB. They can be found here:

/etc/selinux/targeted/src/policy/domains/program/mysqld.te
/etc/selinux/targeted/src/policy/file_contexts/program/mysqld.fc

The latter file defines the file locations.
[1 Sep 2005 1:55] Paul Thompson
Also applied to MySQL-server-4.1.14-0.i386.rpm from mysql.com.  Running FC3 
Linux awss-l1 2.6.12-1.1376_FC3smp #1 SMP Fri Aug 26 23:50:33 EDT 2005 i686 i686 i386 GNU/Linux
[3 Sep 2005 18:19] Jani Tolonen
Here is a patch, which after applying I got MySQL-server-pro-gpl-4.1.15-0.rhel4.i386.rpm
installed without errors, or warnings.

------------------------------------- Beginning of the patch -------------------------------------
*** domains/program/mysqld.te   2005-09-03 20:07:32.028517426 +0200
--- domains/program/mysqld.te.fixed     2005-09-03 20:04:13.468426479 +0200
***************
*** 87,89 ****
--- 87,93 ----
  # because Fedora has the sock_file in the database directory
  file_type_auto_trans(mysqld_t, mysqld_db_t, mysqld_var_run_t, sock_file)
  ')
+
+ allow mysqld_t var_lib_t:dir { write add_name remove_name };
+ allow mysqld_t var_lib_t:file { append create lock read write getattr unlink };
+ allow mysqld_t var_lib_t:sock_file create;
--------------------------------- end of the patch -----------------------------------------------

Here is how to apply:

cd /etc/selinux/targeted/src/policy
patch -p0 < mysql-selinux.patch
make load

Basically what the patch does, is that it gives mysqld executable all required privileges
to manage files in the datadirectory, /var/lib/mysql
This is needed when installing the grant tables. I am not sure how Redhat has built their
corresponding MySQL rpms, but most likely they do grant table installation differently.
Applying the patch should not be any security risk, because it only affects the mysqld binary
and it's own privileges in the database directory.
[3 Sep 2005 18:21] Jani Tolonen
Patch for MySQL-Selinux

Attachment: mysql-selinux.patch (application/octet-stream, text), 520 bytes.

[5 Sep 2005 7:42] Jani Tolonen
Reported bug and proposed a patch to RedHat, ID 167551,
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167551
[5 Sep 2005 18:28] austin woz
i am having similar problem, installing MySQL-server-standard-5.0.12-0.rhel4.x86_64.rpm (AMD64) on CentOs 4.1. during install received error that it could not start mySQL. When i check logs/messages i see the following:
******************
Sep  5 18:05:09 web3 kernel: audit(1125939909.432:0): avc:  denied  { append } for  pid=9393 comm=mysqld path=/var/lib/mysql/web3.err dev=cciss/c0d0p2 ino=455333 scontext=root:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=file
Sep  5 18:05:09 web3 kernel: audit(1125939909.433:0): avc:  denied  { append } for  pid=9393 comm=mysqld path=/var/lib/mysql/web3.err dev=cciss/c0d0p2 ino=455333 scontext=root:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=file
Sep  5 18:05:09 web3 kernel: audit(1125939909.435:0): avc:  denied  { sys_resource } for  pid=9393 comm=mysqld capability=24 scontext=root:system_r:mysqld_t tcontext=root:system_r:mysqld_t tclass=capability
Sep  5 18:05:09 web3 kernel: audit(1125939909.439:0): avc:  denied  { write } for  pid=9393 comm=mysqld name=mysql dev=cciss/c0d0p2 ino=455328 scontext=root:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=dir
Sep  5 18:05:09 web3 kernel: audit(1125939909.439:0): avc:  denied  { write } for  pid=9393 comm=mysqld name=mysql dev=cciss/c0d0p2 ino=455328 scontext=root:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=dir
*******************

i have tried to apply this patch but I do not have the folder 'src' under /etc/selinux/targeted/, and the files
/etc/selinux/targeted/src/policy/domains/program/mysqld.te
/etc/selinux/targeted/src/policy/file_contexts/program/mysqld.fc

Sorry i am fairly new to this, but i would like to get MySQL v5 running so please help me with a work around if you can...(if i set SElinuz to passive, can i set it to enforcing after install)
[5 Sep 2005 18:42] austin woz
in follow up, from an old post i have read this might help me 'restorecon -R -v /var/lib/mysql' yes/no?
[11 Oct 2005 6:35] Lenz Grimmer
Bug #13630 was marked as a duplicate of this bug.
[12 Oct 2005 0:18] Michael Chester
If you are using rhel 4 you can work around this issue by running the security GUI system-config-securitylevel and exempting the MySQL service from the SELinux configuration.  You should then be able to run the RPM install as per the MySQL instructions.  

This is not an ideal solution as the SELinux rule is there for a reason and if you want to do it properly then you will need to educate yourself on the nessecary evils of SELinux and create a properly configured rule for your situation.  

See http://www.nsa.gov/selinux/ or http://selinux.sourceforge.net for starters.  RedHat also produce a document called rhel-pwg-selinux which reputedly explains how to create and configure SELinux policies, but I've never read it.
[31 Oct 2005 10:41] Walery Studennikov
> [31 Oct 10:39] Thomas Hartwig
> Did you do an update with an installed instance before?

I've installed the package using update procedure (rpm -U).
The previous installed version was MySQL 4.1 (from FC4 distro).

> Check if "/var/lib/mysql" belongs to the user "mysql".

Yes, I'lve fixed this by hands.
But /etc/init.d/mysql script doesn't work anyway.
See p.3 in the original bure report message.
[31 Oct 2005 10:44] Walery Studennikov
The previous comment was added by an accident.
It can be removed.
[12 Dec 2005 7:55] Colin Charles
Using audit2allow, we can write our own SELinux rules, and provide it in the RPM package, using conditional statements based on /etc/redhat-release or /etc/fedora-release. While we can get away fairly easily now, FC-5 will actually have SELinux installed by default, and this problem may warrant more bug reports.

Looking at the selinux policy from FC-5 test1 (rawhide currently), a patch on a RHEL4 box should be fairly easy to make.
[4 Jun 2006 3:34] [ name withheld ]
Fix for MySQL 5.0.21 installed using the RPMs from in the TYPO3 v4 installer pack from www.typo3installer.de running on CentOS 4.3 (minimum install)

This may work with other RPMs, or an install from source.

!!WARNING!!: I have no idea what these SELinuxpolicy changes mean!! Proceed at your own risk!! I can confirm they will allow MySQL 5.0.21 to run on CentOS 4.3, without disabling SELinux. They are hopefully not as insecure as telling SELinux to leave MySQL alone entirely or allow it do whatever it wants. Can anyone confirm this??

This is effectively a HOWTO for implementing the changes in Jani Tolonen's patch file above. I've kept as close as I can to the solution offered, I'm not sure which steps are mandatory. Feel free to clean this up as required.

You need basic linux knowledge, in particular you need to know that '#' before a command means run as root and 'vim' is a text file editor, and 'yum' should be used to add packages whenever possible.

From a minimum CentOS install, you will at least need:
selinux-policy-targeted-sources (adding this package will make the 'src' and associated subdirectories appear), vim-enhanced and possibly libselinux-devel. 

1. # setenforce 0

2. # cd /etc/selinux/targeted/src/policy

3a. # vim domains/program/mysqld.te

3b. find the following three (3) lines:
# because Fedora has the sock_file in the database directory
file_type_auto_trans(mysqld_t, mysqld_db_t, mysqld_var_run_t, sock_file)
')

3c. immediately after these three lines, add the following four (4) lines (not including the '+' symbols):
+
+allow mysqld_t var_lib_t:dir { write add_name remove_name };
+allow mysqld_t var_lib_t:file { append create lock read write getattr unlink };
+allow mysqld_t var_lib_t:sock_file create;

4d. save and close the file

5. # make load

6. # setenforce 1
---
Notes: I did not try it exactly as written above, I first installed MySQL (server) from the RPMs, but it wouldn't start. After making the policy changes I was able to start it succesfully. (no reboot required).
[19 Jun 2006 14:27] Kent Boortz
Red Hat has an update that solves this

  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167551
  http://rhn.redhat.com/errata/RHBA-2006-0049.html

The "security policy" specification was updated to handle the install
structure of the RPMs provided by MySQL. No changes in MySQL
packaging was done, this correction is not tied to any special MySQL
version.
[27 Jul 2006 3:09] Paul DuBois
Thank you for your bug report. This issue has been addressed in the documentation. The updated documentation will appear on our website shortly, and will be included in the next release of the relevant products.

I've added a new "SELinux" section in the platform notes section of the installation
chapter pointing out that problems may occur with SELinux installation and
giving the URLs for the Red Hat update that solves the problem.
[21 Oct 2006 0:32] Kolbe Kegel
Verified that the MySQL Server cannot be successfully installed/started on a stock RHEL machine.

1. TRY TO INSTALL A MySQL SERVER RPM

[root@localhost Desktop]# rpm -i MySQL-server-pro-gpl-5.0.26-0.rhel4.i386.rpm
warning: MySQL-server-pro-gpl-5.0.26-0.rhel4.i386.rpm: V3 DSA signature: NOKEY, key ID 5072e1f5
PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER !
To do so, start the server, then issue the following commands:
/usr/bin/mysqladmin -u root password 'new-password'
/usr/bin/mysqladmin -u root -h localhost.localdomain password 'new-password'
See the manual for more instructions.

Please report any problems with the /usr/bin/mysqlbug script!

The latest information about MySQL is available on the web at
http://www.mysql.com
Support MySQL by buying support/licenses at http://shop.mysql.com
Starting MySQL...................................[FAILED]

2. COULDN'T START MYSQL ... LOOK IN /var/log/messages

[root@localhost Desktop]# tail /var/log/messages
[...]
Oct 20 16:43:31 localhost kernel: audit(1161387811.519:2): avc:  denied  { append } for  pid=3997 comm="mysqld" name="localhost.localdomain.err" dev=dm-0 ino=931356 scontext=root:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=file
Oct 20 16:43:31 localhost kernel: audit(1161387811.530:3): avc:  denied  { append } for  pid=3997 comm="mysqld" name="localhost.localdomain.err" dev=dm-0 ino=931356 scontext=root:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=file
Oct 20 16:43:34 localhost kernel: audit(1161387814.807:4): avc:  denied  { create } for  pid=3997 comm="mysqld" name="mysql.sock" scontext=root:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=sock_file

There is a really awful "workaround" for this. You can use the "restorecon" utility to fiddle with the SELinux file metadata for the files already installed by the RPM, then uninstall the RPM, and re-install it.

3. RUN restorecon

[root@localhost Desktop]# restorecon -R /

4. REMOVE MySQL RPM

[root@localhost Desktop]# rpm -e MySQL-server-pro-gpl-5.0.26-0.rhel4

5. RE-INSTALL MySQL RPM

[root@localhost Desktop]# rpm -i MySQL-server-pro-gpl-5.0.26-0.rhel4.i386.rpm
warning: MySQL-server-pro-gpl-5.0.26-0.rhel4.i386.rpm: V3 DSA signature: NOKEY, key ID 5072e1f5
PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER !
To do so, start the server, then issue the following commands:
/usr/bin/mysqladmin -u root password 'new-password'
/usr/bin/mysqladmin -u root -h localhost.localdomain password 'new-password'
See the manual for more instructions.

NOTE:  If you are upgrading from a MySQL <= 3.22.10 you should run
the /usr/bin/mysql_fix_privilege_tables. Otherwise you will not be
able to use the new GRANT command!

Please report any problems with the /usr/bin/mysqlbug script!

The latest information about MySQL is available on the web at
http://www.mysql.com
Support MySQL by buying support/licenses at http://shop.mysql.com
Starting MySQL.[  OK  ]

This is obviously not a reasonable solution, but it does point to some problem in the way the RPMs are built. Perhaps "restorecon" could be run on certain parts of the filesystem after the files are installed but before the server is started. It may also be possible to include a modified SELinux policy with the MySQL RPMs.
[7 Dec 2006 1:47] Alex Syrov
in addition to all comments and [4 Jun 5:34] [ name withheld ]...

Tested Environment CentOS 4.4 x86_64 
Mysql 5.0.27

Installed from MYSQL.com provided binaries for "Red Hat Enterprise Linux 4 RPM (AMD64 / Intel EM64T) downloads"

Right after install mysql did not start because of so I got here to read about CentOS / Red Hat and mysql binaries that don't start (this way more people will find it) 

there some notes below in the thread (patch an d post, but they fail to mention all the steps and required modifications), but I will try to combine them and add more info from my experience.

this is what you actually need to do to make sure mysql works:

1) install SELinux policy sources (otherwise you will have nothing to modify)
# yum install selinux-policy-targeted-sources.noarch

2) open policy as per patch and name withheld instructions
# setenforce 0
# cd /etc/selinux/targeted/src/policy
# vi domains/program/mysqld.te

3) find the following three (3) lines:
# because Fedora has the sock_file in the database directory
file_type_auto_trans(mysqld_t, mysqld_db_t, mysqld_var_run_t, sock_file)
')

4) immediately after these three lines, add the following four (4) lines:
#
allow mysqld_t var_lib_t:dir { write add_name remove_name };
allow mysqld_t var_lib_t:file { append create lock read write getattr unlink };
allow mysqld_t var_lib_t:sock_file { create getattr unlink };
#

5) Save and close the file

6) Compile and load New Policy
# make load
# setenforce 1

Linux will be loading the new policy after the restart automatically, no other modifications are required.
[23 Dec 2006 9:10] Valeriy Kravchuk
Bug #24682 was marked as a duplicate of this one.
[25 Jan 2007 15:41] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/18784

ChangeSet@1.2386, 2007-01-25 16:41:21+01:00, joerg@trift2. +2 -0
  Fixes to get "support-files/RHEL4-SElinux/Makefile" created. bug#12676
[25 Jan 2007 16:51] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/18787

ChangeSet@1.2385, 2007-01-25 17:51:21+01:00, joerg@trift2. +5 -0
  For Linux systems running RHEL 4 (which includes SE-Linux), we need to provide
  additional files that specify some actions which are allowed to the MySQL binaries.
      
  Create a new subdirectory "supportfiles/RHEL4-SElinux" for them, and process it.
  
  This fixes bug#12676.
[1 Feb 2007 15:17] Joerg Bruehe
Fix is pushed into 5.0.36,
queued for 5.1.16.
[5 Feb 2007 12:43] Joerg Bruehe
Backport to 4.1 is still on the to-do list.
[7 Feb 2007 19:02] Paul DuBois
Noted in 5.0.36, 5.1.16 changelogs.

Resetting report to Patch Queued pending backport
to 4.1 tree.
[19 Apr 2007 7:37] Mads Martin Joergensen
I'd been informed a make load would do the same.
[3 Aug 2007 13:30] Daniel Fischer
As of 5.0.46, RHEL4 RPMs print, during installation, instructions on how to fix the SELinux problems on this platform.

Closing as "not a bug" because we ended up not fixing it ourselves.