BUG: Incoherent permissions used by weaver on operations

[jeabapLANG]

With the new incredible feature added in v1.5.0, TLS and MTLS work really well 👍 🥳 !

But it seems it introduced / showed an old bug roaming around which is that, the certificate files are read under (my assumption) another user as the one set to be running the docker which causes an error trying to read them.

For example, running weaver when using the user root which has the rights to open all files on the system, this error shows up :
dns-dnsweaver | {"time":"2026-05-29T18:26:53.20041979+02:00","level":"ERROR","msg":"TLS configuration failed to build, falling back to stdlib defaults","error":"loading TLS client keypair (cert=\"/etc/certs/cert.crt\" key=\"/etc/certs/key.pem\"): open /etc/certs/key.pem: permission denied"}

Using ls -l to show permissions on files :

-rw-r--r-- 1 root root 1273 May 29 18:15 cert.crt
-rw-rw---- 1 root root  288 May 29 18:15 key.pem

And now when applying read/write access to the key file :

-rw-rw-rw- 1 root root  288 May 29 18:15 key.pem

With the new access applied weaver works perfectly !

So I guess it really has something to do with incorrect permissions checked / not the right user used when trying to open the certificates ?

[jeabapLANG]

And by the way, thanks for the great work you're putting in the project,
You deserve so much more stars ;) !

Absolutely love it 🥳 !

PS: Would have loved to help you on it but sadly, I don't know Go, I'm just a C hag roaming around ah ah

[maxfield-allison]

Thanks for the kind words and the great repro — that's enough detail to make the fix obvious. Quick triage:

Root cause (not really a bug, but a sharp edge): the container always drops privileges to a non-root user (dnsweaver, uid/gid 1000) via su-exec in the entrypoint, even when you start the container as root. That's intentional — we don't want the long-running process to keep root just because the docker socket needed it for one-time GID detection — but the consequence is that your cert/key files have to be readable by uid 1000, not by whichever user owns them on the host.

Your key.pem was root:root mode 0640, so root could read it but uid 1000 inside the container could not. The chmod 0666 workaround works but please don't ship that — a private key world-readable in a container is a real downgrade.

Two clean options:

1. Chown on the host (recommended):

   sudo chown 1000:1000 cert.crt key.pem
   sudo chmod 0644 cert.crt
   sudo chmod 0600 key.pem

2. Group-readable if you can't change ownership:

   sudo chgrp 1000 key.pem
   sudo chmod 0640 key.pem

3. Docker secrets (/run/secrets/...) — already world-readable inside the container by design, no chown needed. The Technitium mTLS example in the docs uses this pattern.

What we're going to fix on our end (tracked internally; this is what we'll ship):

• The permission denied error will mention the uid/gid the binary actually runs as, so the next person doesn't burn 20 minutes thinking "but I AM root."
• A short "Mount Permissions" section in the TLS docs, linked from the README and every provider's mTLS example.

Leaving this open until those land in a release; I'll comment back when there's a tag to upgrade to.

(And — no apology needed for not knowing Go. A clean bug report with the actual ls -l output is genuinely more valuable than a half-baked PR. Cheers.)

[jeabapLANG]

Ah ah no problem ;) !

I'm just currently setting up an environment so i'm still in the debugging / dev phase thus the permissions and i was wondering why it was not working with specifically your image. (didn't have any problems with those permissions on all the images/dockers i'm using because they're not doing such strict checks i guess)

If it was intended by design, i'll just keep the permissions like that and write some note about it to change permissions when i ship everything.

Thanks and have a great day !