Bug 138421 - httpd cannot connect to mysqld through socket /var/lib/mysql/mysql.sock
Summary: httpd cannot connect to mysqld through socket /var/lib/mysql/mysql.sock
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
(Show other bugs)
Version: 3
Hardware: i386 Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-11-09 01:46 UTC by Radu Cornea
Modified: 2007-11-30 22:10 UTC (History)
4 users (show)

Fixed In Version: RHBA-2005-251
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-02 17:28:41 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:251 low SHIPPED_LIVE selinux-policy-targeted bug fix update 2005-06-09 04:00:00 UTC

Description Radu Cornea 2004-11-09 01:46:42 UTC
Description of problem:
I installed a program (feedonfeeds, from
http://minutillo.com/steve/feedonfeeds/) that requires access to MYSQL
through sockets. The result is that I get this error from apache:
"Cannot connect to database. Check your configuration. Mysql says:
Can't connect to local MySQL server through socket
'/var/lib/mysql/mysql.sock' (13)"
If I disable selinux protection for httpd (with
system-config-securitylevel, transition), it works fine.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Enable apache, mysqld
2. Install feedonfeeds
3. Try to use it
Actual results:
Error from apache:

Cannot connect to database. Check your configuration. Mysql says:
Can't connect to local MySQL server through socket
'/var/lib/mysql/mysql.sock' (13)

And in /var/log/messages:

Nov  8 17:42:00 localhost kernel: audit(1099964520.223:0): avc: 
denied  { write } for  pid=29807 exe=/usr/sbin/httpd name=mysql.sock
dev=hda1 ino=1209571 scontext=root:system_r:httpd_t
tcontext=root:object_r:var_lib_t tclass=sock_file

Expected results:
Apache (httpd) should have access to /var/lib/mysql/mysql.sock

Additional info:

Comment 1 Jef Spaleta 2004-11-09 04:17:29 UTC
let me ask you a slightly more technical question.
Is the feedonfeeds software trying to access mysql at localhost
or at localhost.localdomain or at

I just helped someone identify similar selinux behavior in #fedora
channel on irc, but with a twist. Selinux disallowed mysql access at
'localhost'  but allowed acess to mysql at 'localhost.localdomain.'  

I would have expected 'localhost' and 'localhost.localdomain' to be
treated similarly by the default targetted selinux policy for httpd,
but they were not.

Sorry for the secondhand report, the person in #fedora quit the
channel as soon as the problem was identified as an selinux bug,
before I could twist their arm to post a report about the inconsistent
treatment of localhost/localhost.localdomain.


Comment 2 John Major 2004-11-09 05:05:30 UTC
Hi Jef,

I apologize for leaving the channel so abruptly as I was just
disabling selinux to try and isolate the problem.  In my case I was
running some custom PHP applications and they would work correctly
when trying to access MySQL from localhost.localdomain however SE
Linux was disallowing MySQL connections from localhost.  The errors I
got were exactly the same as the user reported above and I could stop
the problem by disabling selinux.


Comment 3 Radu Cornea 2004-11-09 09:51:39 UTC
Yes, replacing localhost with localhost.localdomain fixes the error. But now I get an error 
when the httpd process tries to write to a folder within its www docs space. Do I need to 
enable this somehow in selinux? The permissions are fine and it works without selinux.

Comment 4 Daniel Walsh 2004-11-11 14:00:26 UTC
I have added mysql to targeted policy. 


available at ftp://people.redhat.com/dwalsh/SELinux/FC3

You will need to execute

rpm -q -l mysql | restorecon -R -f -

After you install and load the policy. Then stop and restart mysql and

Comment 5 Radu Cornea 2004-11-11 17:08:33 UTC
It works fine with the new policy.


Comment 6 John Major 2004-11-14 09:51:45 UTC
I just installed the new policy and I can confirm it worked for me as

Thank you.

Comment 7 Jean-Francois Saucier 2004-11-15 14:47:36 UTC
I don't work for me...

I installed the rpm with rpm -Uvh

After, I run 
rpm -q -l mysql | restorecon -R -f -

And it says:

Warning! /usr/lib/mysql/libmysqlclient_r.so.10 refers to a symbolic
link, not following last component.
Warning! /usr/lib/mysql/libmysqlclient.so refers to a symbolic link,
not following last component.
Warning! /usr/lib/mysql/libmysqlclient_r.so refers to a symbolic link,
not following last component.
Warning! /usr/lib/mysql/libmysqlclient.so.10 refers to a symbolic
link, not following last component.
Warning! /usr/lib/mysql/libmysqlclient.so.10 refers to a symbolic
link, not following last component.
Warning! /usr/lib/mysql/libmysqlclient_r.so.10 refers to a symbolic
link, not following last component.

I have rebooted, redo the command and mysql continue to not be
accessible on my web page.

It work with localhost.localdomain...

Comment 8 Daniel Walsh 2004-11-15 14:53:14 UTC
What avc messages are you seeing in /var/log/messages?


Comment 9 Jean-Francois Saucier 2004-11-15 14:57:43 UTC
Nov 15 10:00:10 portable kernel: audit(1100530810.467:0): avc:  denied
 { write } for  pid=3449 exe=/usr/sbin/httpd name=mysql.sock dev=hda2
ino=1032288 scontext=root:system_r:httpd_t
tcontext=root:object_r:var_lib_t tclass=sock_file

It's the message I got when trying to view my page

Comment 10 Daniel Walsh 2004-11-15 15:03:39 UTC
This looks like the relabel or package update was not successfull


restorecon -R -v /var/lib
service mysqld restart
service httpd restart

Comment 11 Jean-Francois Saucier 2004-11-15 15:07:49 UTC
Ok, I have tried this and now it says in my dmesg

Nov 15 10:11:56 portable kernel: audit(1100531516.835:0): avc:  denied
 { connectto } for  pid=4375 exe=/usr/sbin/httpd
path=/var/lib/mysql/mysql.sock scontext=root:system_r:httpd_t
tcontext=root:system_r:unconfined_t tclass=unix_stream_socket

Comment 12 Daniel Walsh 2004-11-15 15:26:34 UTC
Still looks like mysql is running with the wrong context.

ps -eZ | grep mysql
Sould be running as mysql_t not unconfined_t

 ls -lZ /usr/libexec/mysqld

should be 
 ls -lZ /usr/libexec/mysqld
-rwxr-xr-x  root     root     system_u:object_r:mysqld_exec_t 

Comment 13 Jean-Francois Saucier 2004-11-15 15:29:39 UTC
The output from ps- -eZ is :

root:system_r:unconfined_t       4360 pts/1    00:00:00 safe_mysqld
root:system_r:unconfined_t       4386 pts/1    00:00:00 mysqld

the output from ls -lZ is :

-rwxr-xr-x  root     root     system_u:object_r:bin_t         

Do I need to chcon -R -t mysqld_exec_t /usr/lib/mysqld ?

Comment 14 Daniel Walsh 2004-11-15 15:33:39 UTC
rpm -q -l mysql | restorecon -R -v -f -

Should relabel it.  Are you sure this ran with only warnings?

restorecon -v /usr/libexec/mysqld should fix it's label.

Comment 15 Jean-Francois Saucier 2004-11-15 15:43:15 UTC
Ok, the output of rpm -q -l mysql | restorecon -R -v -f - is :

Warning! /usr/lib/mysql/libmysqlclient_r.so.10 refers to a symbolic
link, not following last component.
Warning! /usr/lib/mysql/libmysqlclient.so refers to a symbolic link,
not following last component.
Warning! /usr/lib/mysql/libmysqlclient_r.so refers to a symbolic link,
not following last component.
Warning! /usr/lib/mysql/libmysqlclient.so.10 refers to a symbolic
link, not following last component.
Warning! /usr/lib/mysql/libmysqlclient.so.10 refers to a symbolic
link, not following last component.
Warning! /usr/lib/mysql/libmysqlclient_r.so.10 refers to a symbolic
link, not following last component.

The command restorecon -v /usr/libexec/mysqld give the good permission
to mysqld.

Now, I have restarted mysql and it give my this in my dmesg :

Nov 15 10:46:45 portable kernel: audit(1100533605.511:0): avc:  denied
 { connectto } for  pid=4375 exe=/usr/sbin/httpd
path=/var/lib/mysql/mysql.sock scontext=root:system_r:httpd_t
tcontext=root:system_r:mysqld_t tclass=unix_stream_socket

Mayve it's the safe_mysqld binary that cause the problem :

ps -eZ | grep mysql

root:system_r:unconfined_t       4985 pts/1    00:00:00 safe_mysqld
root:system_r:mysqld_t           5009 ?        00:00:00 mysqld

ls -lZ /usr/bin/safe_mysqld 

-rwxr-xr-x  root     root     system_u:object_r:bin_t         

Comment 16 Daniel Walsh 2004-11-15 15:49:31 UTC
No that looks like a bug in policy.

can_unix_connect(httpd_t, mysqld_t)

Adding to selinux-policy-targeted-1.17.30-2.28

Comment 17 Jean-Francois Saucier 2004-11-15 16:01:02 UTC
Ok, so it's normal to have safe_mysqld to that context permission?

Excuse me, I'm a bit new to this selinux stuff and I don't want to
disable it!

When you put the new package online, I just need to rpm -Uvh and
everything will work? Do I need to undo something we have tested?

Thanks a lot for your time and help.

Comment 18 Daniel Walsh 2004-11-15 16:18:11 UTC
Yes that is fine.  We are only protecting mysqld.

rpm -Uvh most of the time should be enough.  The restorecon stuff is
just because we added mysql to targeted policy after the release.

So the initial install does not label its files correctly.  rpm will
label files on install based on the currently installed Policy.  Since
mysql was installed before mysql policy was added, we needed restorecon.

Thanks for helping me make SELinux policy better.

Comment 19 Jean-Francois Saucier 2004-11-17 16:48:42 UTC
Ok, I see that you put the .31 packages on your site.

So, I just need to 

rpm -Uvh selinux-policy-targeted-1.17.30-2.31.noarch.rpm

to install it or I'm better to wait for an official package?


Comment 20 Daniel Walsh 2004-11-17 16:56:10 UTC
You can grab it off my site or wait for the final package.  Basically
these are test packages to fix other problems.

I think 2.30 shoud be in fedora-updates soon.

Comment 21 Niels Basjes 2004-11-20 23:08:01 UTC
I ran into this issue also and installed the   

I ran into the exact same problems as Jeff Saucier.
It took me a while but I figured out why the command

  rpm -q -l mysql | restorecon -R -v -f -

didn't have the desired relabeling effect on the mysqld executable.
The reason is that the mysqld executable is not part of the mysql
package but part of the mysql-server package. So instead I did a 

  rpm -q -l mysql-server | restorecon -R -v -f -
  service mysqld restart
  service httpd restart

and that worked for me.

Comment 22 Jean-Francois Saucier 2004-11-23 16:04:48 UTC
Work fine with the policy update (.33)


Comment 23 James Laska 2004-12-02 17:28:41 UTC
The tested package (selinux-policy-targeted-1.17.30-2.33) appears to resolve the
issue according to feedback.  I am closing this issue.  If the reported problem
resurfaces, please reopen this bug.

Comment 24 David Martos 2004-12-21 23:12:28 UTC
I am using:
And does not work by using localhost, it works by using
localhost.localdomain, so what I need to do to make localhost work?
rpm -q -l mysql-server | restorecon -R -v -f -
rpm -q -l mysql | restorecon -R -v -f -
or it just must work without using the restorecon command?

Comment 25 Gianluca Amato 2005-01-12 08:41:03 UTC
I have the same problem with MySQL-Max-4.1.7 (which is not in the
standard Fedora 3 distro but may be downloaded from www.mysql.com) The
problem seems to be that while /usr/sbin/mysqld has security context
system_u:object_r:sbin_t, /usr/sbin/mysqld-max has the standard
security context system_u:object_r:sbin_t. By manually changing the
context of /usr/sbin/mysqld-max, everything seems to work ok. 

Is it possible to add the right context of /usr/sbin/mysqld-max to the
security policy?

Comment 26 Daniel Walsh 2005-01-12 13:32:59 UTC
Yes I added it to rawhide policy.

Comment 27 Tim Powers 2005-06-09 13:05:38 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.