Key file is world readable

[codewithmartin]

Bug description

keyfile stored in acme.sh/ and also installed to certs/ is world readable (0644). It should be 0600.

[joeyfigaro]

Could use attention

[buchdag]

I'll handle this by the end of the week for files in /etc/nginx/certs.

Unfortunately it looks like we can't touch permissions of private keys stored in /etc/acme.sh without breaking everything.

I'd strongly advise against using bind mounts for the /etc/acme.sh volume (and, personally, against using bind mounts in Docker for pretty much anything else than single configuration files).

edit: or maybe I just did a stupid typo 😒

edit2: yep, I did

[te-online]

Hey there 👋 Is this included in the latest docker tag?

I'm running into an issue with permissions with the latest image. My usecase is that I mount the certs volume into an InfluxDb container to re-use the certificate for its services.

Like so:

# ...
nginx-proxy-letsencrypt:
  <<: [*restart_policy, *network, *logging]
  image: nginxproxy/acme-companion
  container_name: nginx-proxy-lets-encrypt
  depends_on:
    - "nginx-proxy"
  volumes:
    - nginx-certs:/etc/nginx/certs:rw
    - nginx-vhost:/etc/nginx/vhost.d
    - nginx-html:/usr/share/nginx/html
    - nginx-dhparam:/etc/nginx/dhparam
    - nginx-acme:/etc/acme.sh
    - /var/run/docker.sock:/var/run/docker.sock:ro
  environment:
    - DEFAULT_EMAIL=${DEFAULT_EMAIL}
  userns_mode: 'host'

influxdb:
  <<: [*restart_policy, *network, *logging]
  image: influxdb:1.8.10
  container_name: influxdb
  volumes:
    # Mount for influxdb data directory
    - influxdb-data:/var/lib/influxdb
    # Mount for influxdb configuration
    - ./influxdb/config/:/etc/influxdb/
    # Re-use Let's Encrypt certificates for API
    - nginx-certs:/etc/ssl/certs:ro
  ports:
    # The API for InfluxDB is served on port 8086
    - '8086:8086'
    - '8082:8082'
    # UDP Port
    - '8089:8089/udp'
  environment:
    - INFLUXDB_DB=${INFLUXDB_DB}
    - LOGSPOUT=ignore
  env_file:
    - influxdb.env

The InfluxDb container now refuses to start, because its user doesn't have permission to access the certificate.
This is especially complicated, as the InfluxDb container uses user namespace mapping (because it safely can), but acme-companion can't use user namspace mapping from my experience, so we're guaranteed to have different user ids here, making it impossible to re-use the certificates.

Maybe you have a magic idea on how to fix this? 😊

[alterNERDtive]

Yep, similar issue with mounting the certs into the official ZNC image (which runs ZNC as the znc user).

Haven’t had the time to look into fixing it yet though :)

[buchdag]

@te-online @alterNERDtive have you tried the private files ownership and permissions configuration env vars ?

[buchdag]

Also, the usual warning about the latest tag:

General advice about latest

Do not use the latest tag for production setups.

latest is nothing more than a convenient default used by Docker if no specific tag is provided, there isn't any strict convention on what goes into this tag over different projects, and it does not carry any promise of stability.

Using latest will most certainly put you at risk of experiencing uncontrolled updates to non backward compatible versions (or versions with breaking changes) and makes it harder for maintainers to track which exact version of the container you are experiencing an issue with.

This recommendation stands for pretty much every Docker image in existence, not just nginx-proxy's ones.

[te-online]

@buchdag Haven't seen the configuration env vars – thanks a lot for mentioning, it looks like that would fix the problem! I will check it out when I'm back to this project in 2 weeks time.

Yes, I'm aware that latest can include breaking changes, thanks for the reminder 😊

[alterNERDtive]

@te-online @alterNERDtive have you tried the private files ownership and permissions configuration env vars ?

Nope, but I will. Thanks :)

As for using latest, I wouldn’t call my home setup “production”. More like “fun to fiddle with and fix when it breaks”. Coming here was just the first step of that, and as I said, hadn’t had the time to go deeper yet.