Bug 138421 - httpd cannot connect to mysqld through socket /var/lib/mysql/mysql.sock
httpd cannot connect to mysqld through socket /var/lib/mysql/mysql.sock
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-08 20:46 EST by Radu Cornea
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Radu Cornea 2004-11-08 20:46:42 EST
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:
Always

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-08 23:17:29 EST
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 127.0.0.1?

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.

-jef
Comment 2 John Major 2004-11-09 00:05:30 EST
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.

-John
Comment 3 Radu Cornea 2004-11-09 04:51:39 EST
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.
Thanks.
Comment 4 Daniel Walsh 2004-11-11 09:00:26 EST
I have added mysql to targeted policy. 

selinux-policy-targeted-1.17.30-2.23

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
http
Comment 5 Radu Cornea 2004-11-11 12:08:33 EST
It works fine with the new policy.
Thanks.

--
Radu
Comment 6 John Major 2004-11-14 04:51:45 EST
I just installed the new policy and I can confirm it worked for me as
well.  

Thank you.
Comment 7 Jean-Francois Saucier 2004-11-15 09:47:36 EST
I don't work for me...

I installed the rpm with rpm -Uvh
selinux-policy-targeted-1.17.30-2.25.noarch.rpm

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 09:53:14 EST
What avc messages are you seeing in /var/log/messages?

Dan
Comment 9 Jean-Francois Saucier 2004-11-15 09:57:43 EST
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 10:03:39 EST
This looks like the relabel or package update was not successfull

Try 

restorecon -R -v /var/lib
service mysqld restart
service httpd restart
Comment 11 Jean-Francois Saucier 2004-11-15 10:07:49 EST
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 10:26:34 EST
Still looks like mysql is running with the wrong context.

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

Check 
 ls -lZ /usr/libexec/mysqld

should be 
 ls -lZ /usr/libexec/mysqld
-rwxr-xr-x  root     root     system_u:object_r:mysqld_exec_t 
/usr/libexec/mysqld
Comment 13 Jean-Francois Saucier 2004-11-15 10:29:39 EST
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         
/usr/libexec/mysqld


Do I need to chcon -R -t mysqld_exec_t /usr/lib/mysqld ?
Comment 14 Daniel Walsh 2004-11-15 10:33:39 EST
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 10:43:15 EST
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         
/usr/bin/safe_mysqld
Comment 16 Daniel Walsh 2004-11-15 10:49:31 EST
No that looks like a bug in policy.

need
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 11:01:02 EST
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 11:18:11 EST
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 11:48:42 EST
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?

Thanks
Comment 20 Daniel Walsh 2004-11-17 11:56:10 EST
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 18:08:01 EST
I ran into this issue also and installed the   
selinux-policy-targeted-1.17.30-2.33.noarch.rpm

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 11:04:48 EST
Work fine with the policy update (.33)

Thank
Comment 23 James Laska 2004-12-02 12:28:41 EST
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 18:12:28 EST
I am using:
libselinux-1.19.1-8
selinux-policy-targeted-1.17.30-2.51
mysql-server-3.23.58-13
php-mysql-4.3.9-3
mysql-devel-3.23.58-13
mysql-3.23.58-13
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 03:41:03 EST
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 08:32:59 EST
Yes I added it to rawhide policy.
Comment 27 Tim Powers 2005-06-09 09:05:38 EDT
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.

http://rhn.redhat.com/errata/RHBA-2005-251.html

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