Description of problem: Squid is unable to start when SELinux is enforcing: # getenforce Enforcing # systemctl start squid Job for squid.service failed. See "systemctl status squid.service" and "journalctl -xe" for details. # systemctl status squid ● squid.service - Squid caching proxy Loaded: loaded (/etc/systemd/system/squid.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Sun 2016-03-20 17:49:09 AEDT; 1min 13s ago Process: 4065 ExecStop=/usr/sbin/squid -k shutdown -f $SQUID_CONF (code=exited, status=0/SUCCESS) Process: 4358 ExecStart=/usr/sbin/squid $SQUID_OPTS -f $SQUID_CONF (code=exited, status=127) Process: 4346 ExecStartPre=/usr/libexec/squid/cache_swap.sh (code=exited, status=0/SUCCESS) Main PID: 3896 (code=killed, signal=TERM) Mar 20 17:49:09 beren.home systemd[1]: Starting Squid caching proxy... Mar 20 17:49:09 beren.home squid[4358]: /usr/sbin/squid: error while loading shared libraries: cannot restore segment prot after reloc: Permission denied Mar 20 17:49:09 beren.home systemd[1]: squid.service: control process exited, code=exited status=127 Mar 20 17:49:09 beren.home systemd[1]: Failed to start Squid caching proxy. Mar 20 17:49:09 beren.home systemd[1]: Unit squid.service entered failed state. Mar 20 17:49:09 beren.home systemd[1]: squid.service failed. SELinux is preventing /usr/sbin/squid from 'execmod' accesses on the file /usr/sbin/squid. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that squid should be allowed execmod access on the squid file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep squid /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:squid_t:s0 Target Context system_u:object_r:squid_exec_t:s0 Target Objects /usr/sbin/squid [ file ] Source squid Source Path /usr/sbin/squid Port <Unknown> Host (removed) Source RPM Packages squid-3.5.10-1.fc22.x86_64 Target RPM Packages squid-3.5.10-1.fc22.x86_64 Policy RPM selinux-policy-3.13.1-128.28.fc22.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 4.4.6-200.fc22.x86_64 #1 SMP Wed Mar 16 22:13:40 UTC 2016 x86_64 x86_64 Alert Count 2 First Seen 2016-03-20 17:49:09 AEDT Last Seen 2016-03-20 17:51:06 AEDT Local ID 3fe719e1-e14e-4080-ae2c-c3fed9da9491 Raw Audit Messages type=AVC msg=audit(1458456666.823:811): avc: denied { execmod } for pid=4732 comm="squid" path="/usr/sbin/squid" dev="dm-0" ino=9424 scontext=system_u:system_r:squid_t:s0 tcontext=system_u:object_r:squid_exec_t:s0 tclass=file permissive=1 type=SYSCALL msg=audit(1458456666.823:811): arch=x86_64 syscall=mprotect success=yes exit=0 a0=55a9c6a02000 a1=65f000 a2=5 a3=55a9c7284bb8 items=0 ppid=1 pid=4732 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=squid exe=/usr/sbin/squid subj=system_u:system_r:squid_t:s0 key=(null) Hash: squid,squid_t,squid_exec_t,file,execmod Version-Release number of selected component: selinux-policy-3.13.1-128.28.fc22.noarch Additional info: reporter: libreport-2.6.4 hashmarkername: setroubleshoot kernel: 4.4.6-200.fc22.x86_64 type: libreport
Just a note, that report was actually generated while SELinux was in Permissive mode. The same report occurs either way; Squid is able to be started in Permissive mode though.
This is caused by new squid version actually in updates-testing repo for Fedora 22. Squid folks, Any new feature in squid?
Hello! On an updated F23 with .... May 13 18:41:08 INFO Upgraded: selinux-policy-3.13.1-128.28.fc22.noarch May 13 18:41:08 INFO Upgraded: libecap-1.0.0-1.fc22.x86_64 May 13 18:41:12 INFO Upgraded: squid-7:3.5.10-1.fc22.x86_64 May 13 18:41:40 INFO Upgraded: selinux-policy-targeted-3.13.1-128.28.fc22.noarch ..... I still get type=AVC msg=audit(1463154104.351:701): avc: denied { execmod } for pid=4732 comm="squid" path="/usr/sbin/squid" dev="dm-0" ino=673973 scontext=system_u:system_r:squid_t:s0 tcontext=system_u:object_r:squid_exec_t:s0 tclass=file permissive=0 type=AVC msg=audit(1463154104.455:703): avc: denied { execmod } for pid=4769 comm="squid" path="/usr/sbin/squid" dev="dm-0" ino=673973 scontext=system_u:system_r:squid_t:s0 tcontext=system_u:object_r:squid_exec_t:s0 tclass=file permissive=0 type=AVC msg=audit(1463154142.650:705): avc: denied { execmod } for pid=14365 comm="squid" path="/usr/sbin/squid" dev="dm-0" ino=673973 scontext=system_u:system_r:squid_t:s0 tcontext=system_u:object_r:squid_exec_t:s0 tclass=file permissive=0 type=AVC msg=audit(1463154300.285:213): avc: denied { execmod } for pid=875 comm="squid" path="/usr/sbin/squid" dev="dm-0" ino=673973 scontext=system_u:system_r:squid_t:s0 tcontext=system_u:object_r:squid_exec_t:s0 tclass=file permissive=0 type=AVC msg=audit(1463154336.502:311): avc: denied { execmod } for pid=1100 comm="squid" path="/usr/sbin/squid" dev="dm-0" ino=673973 scontext=system_u:system_r:squid_t:s0 tcontext=system_u:object_r:squid_exec_t:s0 tclass=file permissive=1 So in enforced squid is still unable to start, but in permissive mode it works.
I just did a dnf update and saw similar issues ... have this now: squid-3.5.10-1.fc22.x86_64 and my selinux is in enforcing mode, which I don't want to turn off. However I tried to allow in the usual way (see example by the first poster) but that didn't work. # grep squid /var/log/audit/audit.log |audit2allow -M squid ******************** IMPORTANT *********************** To make this policy package active, execute: semodule -i squid.pp # cat squid.te module squid 1.0; require { type squid_t; type squid_exec_t; class file execmod; } #============= squid_t ============== allow squid_t squid_exec_t:file execmod; # semodule -i squid.pp libsepol.print_missing_requirements: squid's global requirements were not met: type/attribute squid_exec_t (No such file or directory). libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory). semodule: Failed! # ll -Z /usr/sbin/squid -rwxr-xr-x. 1 root root system_u:object_r:squid_exec_t:s0 6856352 Mar 8 22:24 /usr/sbin/squid So instead I did this: # chcon -t texrel_shlib_t /usr/sbin/squid # ll -Z /usr/sbin/squid -rwxr-xr-x. 1 root root system_u:object_r:textrel_shlib_t:s0 6856352 Mar 8 22:24 /usr/sbin/squid And now squid starts ok in enforcing mode.
The Pulp upstream bug status is at CLOSED - WONTFIX. Updating the external tracker on this bug.
The Pulp upstream bug priority is at Normal. Updating the external tracker on this bug.
This have been seen in the past for Squid and was caused by mismatch in compiler/libtool flags, resulting in undesired model of linking. This was fixed in Squid package 3.5.2-3.f23 commit b10ea1ad1af585cd2f258000809298aae6340ab8 Author: Henrik Nordstrom <henrik> Date: Tue Mar 17 03:14:46 2015 +0100 Use -fPIC instead of -fpie to keep libtool happy libtool builds some internal table wrongly when using -fpie. But apparently missed when F22 was later updated to Squid-3.5. I have submitted a new squid-3.5.10-5 build for F22 with the needed packaging change backported from F23 which I think will fix this, but I have no F22 machine (real or virtual) to test the change on.
squid-3.5.10-5.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2016-a96ef11fb5
I can't test this either as I'm now on F23, and squid didn't have this issue on F23 after I upgraded to it. Didn't need to apply the chcon. $ ll -Z /usr/sbin/squid -rwxr-xr-x. 1 root root system_u:object_r:squid_exec_t:s0 6879792 Oct 7 2015 /usr/sbin/squid
squid-3.5.10-5.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-a96ef11fb5
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.