Zoneminder issue when caddy runs as root

Question

Zoneminder issue when caddy runs as root

tschettervictor opened this issue a year ago · comments

This plug-in seems to work fine when caddy is running as the www user.
But when caddy runs as root, the streams cut in and out.

I want to run caddy as root in order to bind port 80

{"level":"info","ts":1691180819.7048585,"msg":"cgi: bogus
header line: HTTP/1.0 200 OK"}
{"level":"info","ts":1691180821.219545,"msg":"cgi: copy e
rror: write tcp 192.168.1.156:8000->192.168.1.188:56076:
write: broken pipe"}

This is the error that keeps happening.

Andreas Schneider · Answer 1 · Sat Aug 05 2023 04:57:36 GMT+0800 (China Standard Time)

If binding to port 80 is your only reason for running as root, you should look into capabilities and especially the capability CAP_NET_BIND_SERVICE. If your service is run with that, it is allowed to bind to priviledges ports even if it is not root.

tschettervictor · Answer 2 · Sat Aug 05 2023 05:25:50 GMT+0800 (China Standard Time)

I have other reason, like security.
It’s just easier to run caddy as root.

Possible to set the uid/gid for the cgi process maybe?

Maybe run caddy as root then switch to www?

I’m on FreeBSD btw

Andreas Schneider · Answer 3 · Sat Aug 05 2023 16:03:05 GMT+0800 (China Standard Time)

I have other reason, like security.

Security should be higher when not run as root.
I have not enough knowledge to advice on best practices for FreeBSD though. So I'll have to take your word for it.

Possible to set the uid/gid for the cgi process maybe?

Not without bigger rework or less code-reuse. The cgi.Handler doesn't allow customizing the os.exec calls. So I would have to replicate (or copy and then modify) the whole cgi package just to pass another parameter to the process creation.

Maybe run caddy as root then switch to www?

Not that I am aware of. I think in the age of containers and cgroups, there is simply no good reason to trust a process with forking itself into a lesser-priviledged child process.

So IMO you have these options:

Find out, why the script behaves differently when run as root vs non-root. Maybe it has a "am I root"-check and denies running then?
Wrap the script with something like sudo to run it as a different user.
Run Caddy with less privileges (as a container or something similar ... whatever FreeBSD offers for that).
Run a second Caddy with less privileges and reverse-proxy to it.

tschettervictor · Answer 4 · Sat Aug 05 2023 22:58:31 GMT+0800 (China Standard Time)

Excellent.
I’m linking to a thread with two possible solutions.
Solution