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:
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
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
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.
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
It works fine with the new policy. Thanks. -- Radu
I just installed the new policy and I can confirm it worked for me as well. Thank you.
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...
What avc messages are you seeing in /var/log/messages? Dan
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
This looks like the relabel or package update was not successfull Try restorecon -R -v /var/lib service mysqld restart service httpd restart
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
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
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 ?
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.
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
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
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.
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.
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
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.
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.
Work fine with the policy update (.33) Thank
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.
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?
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?
Yes I added it to rawhide policy.
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