Description of problem: On a freshly installed f33, service varnish won't start as selinux is preventing lto1-wpa from map access on tempfiles. See bz #1892552 for more details. Version-Release number of selected component (if applicable): How reproducible: selinux-policy-3.14.6-29.fc33.noarch Steps to Reproduce: 1. Install Fedora 33 2. dnf update; dnf install gcc make varnish; journalctl -u varnish -f 3. systemctl start varnish Actual results: SELinux is preventing lto1-wpa from map access on the file /tmp/ccTOlFtj.o. Expected results: Varnish starting up as usual. This is a regression from f32. Additional info: Bluntly doing setenforce 0, makes varnish start. FAQ: Why do a daemon want to run gcc? One of the features of varnish that gives its amazing speed, is using gcc behind the scenes to compile its VCL configuration to a dynamic library, and then linking it runtime. Nov 10 16:45:36 f33 varnishd[21887]: Error: Nov 10 16:45:36 f33 varnishd[21887]: Message from C-compiler: Nov 10 16:45:36 f33 varnishd[21887]: lto1: fatal error: Cannot map /tmp/ccs8p4rl.o Nov 10 16:45:36 f33 varnishd[21887]: compilation terminated. Nov 10 16:45:36 f33 varnishd[21887]: lto-wrapper: fatal error: gcc returned 1 exit status Nov 10 16:45:36 f33 varnishd[21887]: compilation terminated. Nov 10 16:45:36 f33 varnishd[21887]: /usr/bin/ld: error: lto-wrapper failed Nov 10 16:45:36 f33 varnishd[21887]: collect2: error: ld returned 1 exit status Nov 10 16:45:36 f33 varnishd[21887]: Running C-compiler failed, exited with 1 Nov 10 16:45:36 f33 varnishd[21887]: VCL compilation failed
Hi, Is this the only denial you see now? type=AVC msg=audit(1604000868.64:265): avc: denied { map } for pid=23973 comm="lto1-wpa" path="/tmp/ccUUg65n.o" dev="tmpfs" ino=56637 scontext=system_u:system_r:varnishd_t:s0 tcontext=system_u:object_r:varnishd_tmp_t:s0 tclass=file permissive=0
Yes, that is the only one I get.
I've submitted a Fedora PR to address the issue: https://bugzilla.redhat.com/show_bug.cgi?id=1890884#c7
The default domain_can_mmap_files off was added for security reasons: # dnf install selinux-policy-devel # semanage boolean -l | grep domain_can_mmap_files domain_can_mmap_files (on , off) Allow any process to mmap any file on system with attribute file_type. A quick and dirty workaround is to switch if on again: # setsebool domain_can_mmap_files on Se for example here for some notes on the security impact: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.6_release_notes/new_features_security
The issue will be resolved allowing just one map permission, see the PR - this is the correct link: https://github.com/fedora-selinux/selinux-policy-contrib/pull/363
commit 2b2a20eb1be3213fd8d3b3e2f474e8e8790ce7ce (HEAD -> f33, upstream/f33) Author: Zdenek Pytela <zpytela> Date: Thu Nov 12 11:19:01 2020 +0100 Allow varnish map its private tmp files Resolves: rhbz#1896457
FEDORA-2020-aff0be81b3 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-aff0be81b3
FEDORA-2020-aff0be81b3 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-aff0be81b3` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-aff0be81b3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-aff0be81b3 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
*** Bug 1892552 has been marked as a duplicate of this bug. ***