|Summary:||www/caddy: rc.d/caddy requires admin API for stopping|
|Product:||Ports & Packages||Reporter:||Thijs van Dien <thijs>|
|Component:||Individual Port(s)||Assignee:||Adam Weinberger <adamw>|
|Severity:||Affects Some People||Flags:||bugzilla:
Description Thijs van Dien 2021-04-16 04:36:05 UTC
Caddy can be controlled using an admin API endpoint that it serves on localhost:2019. Having that enabled is not ideal from a security perspective, because any user able to log in may connect to it. Disabling it with `admin off` in the global config breaks `service caddy reload` as well as `service caddy stop`. The former (as of Caddy 2) does not appear to have an alternative anymore, but perhaps at least the latter could be rewritten using to make use of `kill`? Meanwhile, I'll then file an issue with the Caddy project so we can hopefully fix reloading after.
Comment 1 Adam Weinberger 2021-04-16 17:07:59 UTC
I was wondering about that. It's certainly not ideal; I'd far prefer to have the admin API off. Caddy doesn't document which signals it responds to. It'd be nice to have a graceful shutdown signal, a reload signal, and a reopen logs signal, but I have no idea which (if any) of those it responds to.
Comment 2 Thijs van Dien 2021-04-16 17:44:53 UTC
Here's a comment I found in the source: "trapSignalsCrossPlatform captures SIGINT or interrupt (depending on the OS), which initiates a graceful shutdown. A second SIGINT or interrupt will forcefully exit the process immediately." The reload signal I brought up here: https://github.com/caddyserver/caddy/issues/3967#issuecomment-820943864. Not sure what you mean by reloading logs?
Comment 3 Thijs van Dien 2021-04-16 17:45:53 UTC
Correction: reopening logs.