thanks for the reply.
# version used
/usr/local/bin/caddy --version
Caddy v1.0.4 (h1:wwuGSkUHo6RZ3oMpeTt7J09WBB87X5o+IZN4dKehcQE=)
caddy can be started as root with runuser: (consider it a workaround, but would still be nice if it would autostart as systemd service)
runuser -l caddy -c '/usr/local/bin/caddy -conf /etc/caddy/caddy.proxy.config'
binary has chmod ugo+x
ll /usr/local/bin/caddy
-rwxr-xr-x. 1 1002 1002 21M Nov 21 11:53 /usr/local/bin/caddy
caddy user has uid: 992
cat /etc/passwd|grep caddy
caddy:x:992:989::/var/www:/bin/bash
tried to fix it like this:
chown -R caddy:caddy /usr/local/bin/caddy
# allow non root users to bind to privileged ports (below 1000) 80/443
# https://superuser.com/questions/710253/allow-non-root-process-to-bind-to-port-80-and-443
setcap CAP_NET_BIND_SERVICE=+eip /usr/local/bin/caddy
systemctl start caddy.service
[root@domain.com ~]# systemctl status caddy.service
● caddy.service - Caddy HTTP/2 web server
Loaded: loaded (/etc/systemd/system/caddy.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Sun 2020-01-19 16:24:15 CET; 1s ago
Docs: https://caddyserver.com/docs
Process: 1119 ExecStart=/usr/local/bin/caddy -log stdout -log-timestamps=false -agree=true -conf=/etc/caddy/caddy.proxy.config -root=/var/tmp (code=exited, status=203/EXEC)
Main PID: 1119 (code=exited, status=203/EXEC)
Jan 19 16:24:15 domain.com.info systemd[1]: Started Caddy HTTP/2 web server.
Jan 19 16:24:15 domain.com.info systemd[1]: caddy.service: Main process exited, code=exited, status=203/EXEC
Jan 19 16:24:15 domain.com.info systemd[1]: caddy.service: Failed with result 'exit-code'.
… service still refuses to start.
this log file might have interesting details:
==> /var/log/audit/audit.log <==
type=SERVICE_START msg=audit(1579447742.468:392093): 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=success'UID="root" AUID="unset"
type=AVC msg=audit(1579447742.483:392094): avc: denied { mounton } for pid=1201 comm="(caddy)" path="/run/systemd/unit-root/etc/ssl/caddy" dev="dm-0" ino=100783586 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:cert_t:s0 tclass=dir permissive=0
type=AVC msg=audit(1579447742.484:392095): avc: denied { execute } for pid=1201 comm="(caddy)" name="caddy" dev="dm-0" ino=34595259 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0
type=SERVICE_STOP msg=audit(1579447742.487:392096): 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'UID="root" AUID="unset"
this seems to be the same problem: https://github.com/caddyserver/caddy/issues/2203
https://bugzilla.redhat.com/show_bug.cgi?id=1608548
it reads like this:
"Currently caddy is reusing httpd file labels to function with selinux enforcing.
https://src.fedoraproject.org/rpms/caddy/c/b85070ce0561800bcb5a2eeec08f5896786e2f68
That approach has the benefit of not having to maintain a caddy-specific policy. You’ve discovered a drawback to that approach, which is that selinux doesn’t think that httpd_exec_t type should be binding to 80/udp and 443/udp. I was hoping that I could just report this as bug on the httpd policy, but then I discovered that httpd doesn’t support QUIC, so it probably wouldn’t get much traction.
I’m going to do a bit more research and see what the best path forward would be."
actually using the caddy.service file from here: https://github.com/caddyserver/caddy/tree/master/dist/init/linux-systemd
)