[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: SELinux and MySQL

Okay, I'm new to SELinux and RHEL 4.  

I did a standard install for AS 4, and I enabled SELinux.  So, yes, I do
have SELinux configured to protect daemons.

Just out of curiousity - where can I read more about SELinux w/ RedHat
and how to use it?


-----Original Message-----
From: Manuel Arostegui Ramirez [mailto:manuel todo-linux com] 
Sent: Tuesday, August 15, 2006 5:49 PM
To: golharam umdnj edu
Cc: 'General Red Hat Linux discussion list'
Subject: Re: SELinux and MySQL

El Martes, 15 de Agosto de 2006 23:42, Ryan Golhar escribió:
> Sorry I should have been more clear.  I knew that too.
> If SELinux is enable, I cannot start the mysql daemon using 
> "/etcd/init.d/mysql start".  I have to disable it first.
> If I try to access a mysql database with SELinux enabled, I get an 
> error about the file being corrupt:
> ERROR 1194 (HY000): Table 'user' is marked as crashed and should be 
> repaired
> If I call '/usr/sbin/setenforce 0' prior to using mysql, all works 
> well (all being relative by what I've tried).
> Ryan

Look at this:

"A co-worker recently came to me with an interesting and mysterious
He was setting up a Red Hat Enterprise 4 based machine with MySQL, using
default setup except he'd changed the location of MySQL's data directory

from /var to a different partition. Now MySQL wasn't starting properly.

The symptoms were really funny: the init.d script installed by the
didn't work, except if he ran it by hand with 'sh -x', it did. So he
it out of the way and grabbed a copy from another RHEL4 machine with a 
working MySQL, which worked. But it turned out that the two scripts were

identical. So why did the new one from the other machine work but the
old one 
from the install not work?

(This was where he called me in.)

Fortunately I had been recently reading a series of articles on SELinux;

something about the whole situation tickled the back of my mind, and a
light labeled 'file contexts' lit up. A quick lsattr showed that the two

scripts had different contexts; the 'as installed' one had a special
and the one copied from the other system had a generic one.

And this was the problem: the SELinux MySQL context lacked the magic
permissions to access the new data directory location, because (of
the new location hadn't been SELinux labeled as a MySQL area. However,
normal root context could access everything fine.

(In Red Hat's SELinux setup, many daemons are deliberately run with
SELinux-imposed restrictions so that if someone finds and exploits a 
vulnerability in the daemon it does less damage.)

So when the original MySQL init.d script was run directly, it switched
the MySQL SELinux context and failed to access its data directory.
special contexts on a shell script only get switched into when you
the shell script directly, so when the original script was run via 'sh
-x' it 
was instead running in the normal root context, could access its data 
directory, and worked fine. The copied script always ran in the normal
context since it was not specially labeled, so it worked fine all the

(We tested this guess by running the original init.d script with just
'sh mysql start' instead of 'sh -x mysql start', and it worked fine then


I believe my co-worker's workaround was to turn off SELinux, on the
that he didn't want to try wrestling with that particular pig right

Is your SeLinux configured to protect daemons?
Manuel Arostegui Ramirez.

Electronic Mail is not secure, may not be read every day, and should not
be used for urgent or sensitive issues.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]