New comment by chexum on void-packages repository

https://github.com/void-linux/void-packages/issues/44500#issuecomment-1595969943

Comment:
Not running caddy as root is good.  The suggested changes to use setpriv makes it work in an equivalent way.  I am using caddy, and I am running with those changes. (Might need to change runtime pkg dependencies, as chpst does not have this, well, capability)

If Alpine distributes a setcap binary, then they too have an issue.  Capabilities are not meant to be given to binaries that don't verify their uses. They are a responsibility of things split from the all-powerful root permissions.  The binary installed here allows everyone to bind to nonprivileged ports, which normally is restricted to root. With this binary, it's possible to do that by any user.  This might be a CVE level issue.  It's not with caddy, caddy does not expect users to have this capability - it's only making single user development easier, but bad on a generic Linux/Unix system in general.

This is what Apache has to say about the scheme if used for development:
"with this setup, any nonprivileged user can now run Apache on privileged ports. So, be very careful about what you do. Additionally, you can further restrict execution of the httpd binary, either using standard credentials (chmod, chown et al) or, even better, ACLs;" (https://cwiki.apache.org/confluence/display/httpd/NonRootPortBinding)

Allow me to describe a full demonstration of what the problem is:

(void with no caddy installed, just to not disturb the configuration):
```
xbps-install -Su caddy
umask 022
mkdir /tmp/q1
echo good >/tmp/q1/myfile
sudo vi /etc/caddy/Caddyfile
contents:
http://localhost:80, http://127.0.0.1:80 {
  root * /tmp/q1
  file_server browse
}
ln -s /etc/sv/caddy /var/service
```

expected result:
`curl -v http://localhost/myfile` should work (as any user), no issue as web service was explicitly configured by root

after stopping it with `sv stop caddy` (again, not necessary, only to make the following configuration simpler without documenting the full way to take over a service port in case the caddy process is still running.)

as a nonroot user:
```
umask 022
mkdir /tmp/q2
echo badport >/tmp/q2/myfile
vi $HOME/Caddyfile
contents:
http://127.0.0.1:334 {
  root * /tmp/q2
  file_server browse
}
caddy run --config $HOME/Caddyfile
```
Now, in another window, `curl -v http://127.0.0.1:334/myfile` produces the file contents on a privileged port, while the user `caddy` is run by the user.  Only root should be able to start caddy this way, no exceptions.  No addition verification of ports is done.  This could take over ssh or smtp ports (as an example) if they are not in use, or provide an opportunity to take them over during service restarts.