New issue by chexum on void-packages repository

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

Description:
### Is this a new report?

Yes

### System Info

Void 6.3.6_1 x86_64 AuthenticAMD uptodate F

### Package(s) Affected

caddy-2.6.4_2

### Does a report exist for this bug with the project's home (upstream) and/or another distro?

Possibly not, it's directly related to the package's INSTALL file using setcap, which contradicts recommended operational practices.

### Expected behaviour

caddy, when started by activating it in /var/service, should be able to open privileged ports such as 443 and 80, but it should not grant this permission to users in general.

### Actual behaviour

When the caddy package is installed (does not even need to run), can squat on privileged ports as it has a capabilities directly set on the binary.

### Steps to reproduce

Have a Caddyfile with the contents:
```
http://localhost:23 {
        root * /tmp
        file_server browse
}
```
`caddy run --config ./Caddyfile` then happily starts a server on port 23, when started as a normal user.  (With an already running caddy with an enabled admin port, a minimal addition is needed for success)

I don't think this is desirable.  Other distributions normally use systemd to grant this capability only the caddy service installed/started by the system, not to the installed binary.

I recommend dropping the INSTALL file with setcap, and instead of chpst (as it doesn't seem to be capabilities aware), perhaps use setpriv for a similar effect:

```
exec setpriv --reuid caddy --regid caddy --clear-groups \
  --ambient-caps -all,+net_bind_service \
  --inh-caps -all,+net_bind_service \
  --bounding-set -all,+net_bind_service \
  --no-new-privs -- caddy run ${OPTS} --config ${CONFFILE:-/etc/caddy/Caddyfile}
```

This has been tested to provide functionality matching the current setup when run via a /var/service link, but not allowing any user to squat unused privileged ports with a configuration in their control.