Description of problem: php-fpm fails to start when SELinux enabled Version-Release number of selected component (if applicable): selinux-policy-3.11.1-25.fc18.noarch How reproducible: Always Steps to Reproduce: 1. systemctl start php-fpm.service 2. systemctl status php-fpm.service Actual results: php-fpm.service - The PHP FastCGI Process Manager Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; disabled) Active: active (running) since Mon, 01 Oct 2012 15:20:57 +0200; 8min ago Main PID: 16688 (php-fpm) CGroup: name=systemd:/system/php-fpm.service └ 16688 /usr/sbin/php-fpm --nodaemonize Expected results: php-fpm.service - The PHP FastCGI Process Manager Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; disabled) Active: active (running) since Mon, 01 Oct 2012 15:30:32 +0200; 3s ago Main PID: 21380 (php-fpm) CGroup: name=systemd:/system/php-fpm.service ├ 21380 php-fpm: master process (/etc/php-fpm.conf) ├ 21383 php-fpm: pool www ├ 21384 php-fpm: pool www ├ 21385 php-fpm: pool www ├ 21386 php-fpm: pool www └ 21387 php-fpm: pool www Oct 01 15:30:32 laptop.rcollet.redhat.com php-fpm[21380]: [01-Oct-2012 15:30:32] NOTICE: fpm is running, pid 21380 Oct 01 15:30:32 laptop.rcollet.redhat.com php-fpm[21380]: [01-Oct-2012 15:30:32] NOTICE: ready to handle connections Additional info: In audit.log, lot of messages (php-fpm try to detach process, fails, retry, ...) type=AVC msg=audit(1349097657.376:437): avc: denied { read } for pid=16688 comm="php-fpm" name="urandom" dev="devtmpfs" ino=6609 scontext=system_u:system_r:phpfpm_t:s0 tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file type=SYSCALL msg=audit(1349097657.376:437): arch=c000003e syscall=2 success=no exit=-13 a0=3af4d5abd3 a1=900 a2=4130 a3=7fff41de1e80 items=0 ppid=1 pid=16688 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="php-fpm" exe="/usr/sbin/php-fpm" subj=system_u:system_r:phpfpm_t:s0 key=(null) type=AVC msg=audit(1349097657.377:438): avc: denied { read } for pid=16688 comm="php-fpm" name="random" dev="devtmpfs" ino=6608 scontext=system_u:system_r:phpfpm_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file type=SYSCALL msg=audit(1349097657.377:438): arch=c000003e syscall=2 success=no exit=-13 a0=3af4d5abe0 a1=900 a2=4130 a3=7fff41de1e80 items=0 ppid=1 pid=16688 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="php-fpm" exe="/usr/sbin/php-fpm" subj=system_u:system_r:phpfpm_t:s0 key=(null) type=AVC msg=audit(1349097660.389:445): avc: denied { write } for pid=16688 comm="php-fpm" name="private" dev="tmpfs" ino=126449 scontext=system_u:system_r:phpfpm_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir type=SYSCALL msg=audit(1349097660.389:445): arch=c000003e syscall=2 success=no exit=-13 a0=7fff41de20e0 a1=c1 a2=180 a3=50bcaa47a82 items=0 ppid=1 pid=16688 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="php-fpm" exe="/usr/sbin/php-fpm" subj=system_u:system_r:phpfpm_t:s0 key=(null) Can provide more information if needed, and test.
Could you switch to permissive mode and collect all AVC msg?
Created attachment 620240 [details] additional php fpm avc denials Getting this phpfpm module to work is going to be hard. Consider all the apache_content_template create types that phpfpm_t potentially needs to operate on. It would be much easier to just run php-fpm in the httpd_t domain. Ofcourse then php-fpm can affect the web servers and vice versa but at least it is contained to httpd_t. Getting phpfpm to run in httpd_t should be as simple as: <grift> chcon -R -t httpd_var_run_t /run/php-fpm <grift> chcon -R -t httpd_log_t /var/log/php-fpm <grift> chcon -R -t httpd_exec_t /usr/sbin/php-fpm <grift> semanage port -a -t http_port_t -p tcp 9000 Does the work of confining phpfpm justify the added security, that is the question
If can do everything that httpd_t can do, then it is not worth separating it out.
*** Bug 860746 has been marked as a duplicate of this bug. ***
*** Bug 872839 has been marked as a duplicate of this bug. ***
commit f46519e2adbcd5f7c0475fa400991de429066cd1 Author: Miroslav Grepl <mgrepl> Date: Mon Nov 5 10:17:10 2012 +0100 Treat php-fpm with httpd_t * Fixes many bugs #861975
selinux-policy-3.11.1-50.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/selinux-policy-3.11.1-50.fc18
Package selinux-policy-3.11.1-50.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.11.1-50.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-17705/selinux-policy-3.11.1-50.fc18 then log in and leave karma (feedback).
selinux-policy-3.11.1-50.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
Not sure if it's correct place to comment, but I still see problems with mysql connect: type=AVC msg=audit(1420283018.610:48277): avc: denied { name_connect } for pid=23987 comm="php-fpm" dest=3306 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:mysqld_port_t:s0 tclass=tcp_socket type=SYSCALL msg=audit(1420283018.610:48277): arch=c000003e syscall=42 success=yes exit=0 a0=4 a1=dd9e50 a2=10 a3=0 items=0 ppid=18586 pid=23987 auid=4294967295 uid=1002 gid=1002 euid=1002 suid=1002 fsuid=1002 egid=1002 sgid=1002 fsgid=1002 tty =(none) ses=4294967295 comm="php-fpm" exe="/usr/sbin/php-fpm" subj=system_u:system_r:httpd_t:s0 key=(null) This is not Fedora and not official php-fpm though, it's centos 7 with: $ rpm -qa php-fpm php-fpm-5.4.36-1.el7.remi.x86_64 $ rpm -qa selinux-policy selinux-policy-3.12.1-153.el7_0.13.noarch So it might be remi packaging problem.
Obviously not (In reply to Vladimir Rusinov from comment #10) > Not sure if it's correct place to comment, but I still see problems with > mysql connect: Obviously, not the correct place.
Ah, I figured it out. Since my mysqld was on another host, I had to do setsebool -P httpd_can_network_connect 1. silly me :(