search

mjl- / mox

modern full-featured open source secure mail server for low-maintenance self-hosted email
https://www.xmox.nl
MIT License
3.7k stars 111 forks source link

host private key: permission denied #208

Open MaikuMori opened 3 months ago

MaikuMori commented 3 months ago

I'm trying to setup with caddy, but I'm getting:

reading host private key: open /var/lib/caddy/acme/acme-v02.api.letsencrypt.org-directory/users/xxxxx@xxxxxx.com/xxxxxxxx.key: permission denied" pkg=mox

Could it be that the key is being read after permissions have been dropped?

mox manages to read KeyCerts just fine which have the same permissions as host key.

MaikuMori commented 3 months ago

Looks like that's the case: https://github.com/mjl-/mox/blob/594182aae5881c4c4f5e8caacaab8c25cea7e3c8/mox-/config.go#L1883

Is this a bug or intended?

mjl- commented 2 months ago

@MaikuMori Thanks for reporting! I took a quick look at that code, and I don't see a reason why we couldn't use the same privileged-reading for the host key. So I think we can consider this a bug. I hope to get to this soon (but have a bit of a backlog), feel free to try implementing a fix if you're interested and have the time, I could give some pointers.

mjl- commented 1 month ago

@MaikuMori I realized there may be some rationale for mox reading the host key in the unprivileged process but not for regular tls cert/keys.

For the regular tls cert/keys, an external (acme) tool managing certs may generate a new key and get a new certificate, then reload mox. It helps that mox reads the files as root, so it has access regardless of permissions set by the external tool on new files.

But for host keys, with DANE, the tls private key must not change. If the private key changes, you need to set new dane tlsa dns records too. The best solution at the moment is to have the external acme tool use the same private key for new certificates. In that situation, it isn't too bad to copy that key to a place where the mox unprivileged uid has access to it. It is a one-time configuration action. New certificates are probably world-readable, so the unprivileged mox process should be able to read them, also after the external acme tool has retrieved new certs and restarted mox.