Bug 1706651 - SELinux is preventing caddy from mounton on the directory /run/systemd/unit-root/var/lib/caddy
Summary: SELinux is preventing caddy from mounton on the directory /run/systemd/unit-r...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 30
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-05-06 00:02 UTC by Carl George
Modified: 2022-09-23 07:09 UTC (History)
7 users (show)

Fixed In Version: selinux-policy-3.14.3-52.fc30
Clone Of:
Environment:
Last Closed: 2019-11-17 01:12:55 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Carl George 2019-05-06 00:02:03 UTC
Description of problem:
SELinux blocks caddy from starting in Fedora 30.

Version-Release number of selected component (if applicable):
selinux-policy-3.14.3-32.fc30
caddy-0.11.4-1.fc30

How reproducible:
always

Steps to Reproduce:
1. systemctl start caddy

Actual results:
May 05 18:50:45 zeratul systemd[1]: Starting Caddy HTTP/2 web server...
May 05 18:50:45 zeratul audit[20561]: AVC avc:  denied  { mounton } for  pid=20561 comm="(caddy)" path="/run/systemd/unit-root/var/lib/caddy" dev="dm-0" ino=41163184 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:httpd_var_lib_t:s0 tclass=dir permissive=0
May 05 18:50:45 zeratul systemd[20561]: caddy.service: Failed to set up mount namespacing: Permission denied
May 05 18:50:45 zeratul systemd[20561]: caddy.service: Failed at step NAMESPACE spawning /usr/bin/caddy: Permission denied
May 05 18:50:45 zeratul systemd[1]: caddy.service: Control process exited, code=exited, status=226/NAMESPACE
May 05 18:50:45 zeratul systemd[1]: caddy.service: Failed with result 'exit-code'.
May 05 18:50:45 zeratul systemd[1]: Failed to start Caddy HTTP/2 web server.
May 05 18:50:45 zeratul audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=caddy comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'

Expected results:
successful start of service

Additional info:
The path /run/systemd/unit-root/var/lib/caddy doesn't exist on my system.  I think this is related to these unit file directives.

ProtectSystem=strict
ReadWriteDirectories=/var/lib/caddy

If I downgrade ProtectSystem to full and remove ReadWriteDirectories, caddy can start.

I noticed bug 1648864 and bug 1636823 that look similar, but those are against Fedora 29.  Caddy can start just fine in Fedora 29, this behavior is new in Fedora 30.

Comment 1 Fedora Update System 2019-05-09 17:49:21 UTC
caddy-0.11.4-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-e561daacc5

Comment 2 Fedora Update System 2019-05-10 02:06:19 UTC
caddy-0.11.4-2.fc30 has been pushed to the Fedora 30 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-2019-e561daacc5

Comment 3 Fedora Update System 2019-05-18 01:01:54 UTC
caddy-0.11.4-2.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.

Comment 4 Carl George 2019-05-18 03:04:42 UTC
I opened this issue under the selinux-policy component to get feedback on the denial.  The update I pushed just switches from ProtectSystem=strict to ProtectSystem=full.  What is the correct way to use ProtectSystem=strict and ReadWriteDirectories with SELinux enforcing as it worked in F29?

Comment 5 Ralf Ertzinger 2019-05-30 17:50:27 UTC
Subscribing to this because I'm seeing the exact same effect, for a different unit file. Funnily enough, only for _some_ unit files, and I can't figure out what the difference between the working ones and the non-working ones is.

Comment 6 Lukas Vrabec 2019-10-22 19:16:55 UTC
Carl, 

I added fixes in selinux-policy:
https://github.com/fedora-selinux/selinux-policy-contrib/commit/99b1edeb1a7da9489bc2f4fc87b310ceafaf633e

Feel free to move the bugzilla ticket to selinux-policy component.

Comment 7 Carl George 2019-10-24 15:53:11 UTC
Thanks Lukas.

Comment 8 Fedora Update System 2019-10-26 17:02:37 UTC
FEDORA-2019-f83217e2bf has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-f83217e2bf

Comment 9 Fedora Update System 2019-10-27 03:54:35 UTC
selinux-policy-3.14.3-51.fc30 has been pushed to the Fedora 30 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-2019-f83217e2bf

Comment 10 Fedora Update System 2019-11-03 14:10:36 UTC
FEDORA-2019-70d80ad4bc has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-70d80ad4bc

Comment 11 Fedora Update System 2019-11-04 02:10:00 UTC
selinux-policy-3.14.3-52.fc30 has been pushed to the Fedora 30 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-2019-70d80ad4bc

Comment 12 Fedora Update System 2019-11-17 01:12:55 UTC
selinux-policy-3.14.3-52.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.


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