Docker-letsencrypt-nginx-proxy-companion: Permissions are not being set with env variables

[desimaniac]

Pigging back on to #461 and #463. Does not look it's honoring the FILES_GID and FILES_UID environmental variables, as new files are being created as root. Made sure I was using the latest image.

Docker inspect info: https://pastebin.com/ZKiy7jcD

Thanks.

[buchdag]

Do you have the container's log output ?

What OS and docker version are you using ? Anything specific on your host like SELinux or AppArmor?

[desimaniac]

Just the standard log before all the certs info.

Info: Custom Diffie-Hellman group found, generation skipped.
Reloading nginx proxy (735fda5135b676609d52e57749c6e7879449d3263542a6a99f0183e6ddb5f7be)...
2018/11/23 08:28:32 Contents of /etc/nginx/conf.d/default.conf did not change. Skipping notification ''
2018/11/23 08:28:32 [notice] 91#91: signal process started
2018/11/23 08:28:36 Generated '/app/letsencrypt_service_data' from 18 containers
2018/11/23 08:28:36 Running '/app/signal_le_service'
2018/11/23 08:28:36 Watching docker events
2018/11/23 08:28:36 Contents of /app/letsencrypt_service_data did not change. Skipping notification '/app/signal_le_service'

Server: Ubuntu 16.04 LTS with 4.18.6 kernel. No SELinux or AppArmor enabled.

[buchdag]

Debugging info about the permissions changes are in the middle of the certs info.

[desimaniac]

I dont see any such info. Even with debug env set to true.

Do still see this: Debugging tips: -v improves output verbosity. Help is available under --help..

[buchdag]

Are you sure you are using an up to date version of the container ?

[desimaniac]

Removed the containers and images and pulled and rebuilt.

docker images:

jrcs/letsencrypt-nginx-proxy-companion   latest              56cc2f664c54        10 hours ago        84.8MB

docker inspect:

sha256:56cc2f664c54a2fb587c21969065ab053c4c95aace43ad0d9a6e195b8a036041

docker inspect --format='{{json .Config.Env}}' letsencrypt | jq .
[
  "DEBUG=True",
  "FILES_GID=1000",
  "FILES_UID=1000",
  "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
  "DOCKER_HOST=unix:///var/run/docker.sock"
]

[techoutlooks]

same issue here. thanks @desimaniac for tracking down the bug.

[buchdag]

@techoutlooks > OS, Docker version, LE companion version, config, container logs ?

@desimaniac > my bad, you don't have debug output enabled at all. The value you have to set the DEBUG environment variable to is true, not True. I'll make this case insensitive asap.

[desimaniac]

Ok set debug as true... created a new subdomain: strm.domain.com

Debug: setting /etc/nginx/certs/strm.domain.com/.companion ownership to 1000:1000.
Debug: setting /etc/nginx/certs/strm.domain.com/cert.pem ownership to 1000:1000.
Debug: setting /etc/nginx/certs/strm.domain.com/key.pem ownership to 1000:1000.
Debug: setting /etc/nginx/certs/strm.domain.com/chain.pem ownership to 1000:1000.
Debug: setting /etc/nginx/certs/strm.domain.com/fullchain.pem ownership to 1000:1000.

It does say that it's changing ownership there in the log... and the folder for it (inside where /etc/nginx/certs/ points to) is owned by 1000, but the symlink files are still owned by root.

Inside the folder, the files are owned by 1000 (except the symlink for account_key.json).

[buchdag]

Okay, I see. Are you experiencing issues because of the symlinks being owned by root:root ?

[desimaniac]

Yes, I believe so.

[buchdag]

Can you describe more precisely the issue your are running into because of the symlink ownership ? Does your cert folder has the sticky bit set ?

From the test I just did, symlinks ownership does not appear to matter : even an unprivileged user can mv or rm a symlink owned by root:root. That was tested on Alpine, Ubuntu and Manjaro. If you are on RHEL / CentOS maybe that's different ?

[desimaniac]

Using Ubuntu. I am able to rm fine. I guess that was my only issue: rm ing or tarring up / untarring, etc.

[buchdag]

Could you test it (taring / untaring and the other operations you had in mind) to be sure it's not impacting you in your intended usage of the files ?

[desimaniac]

Tested tarring. Not an issue. So i guess everything is working within parameters 😛 .

Just need a minor tweak the the dubug variable to accept any case.

Thank You!

[buchdag]

Sure it's working within parameter but the fact you thought this was a bug means not changing symlinks ownership might cause confusion.

@techoutlooks is your issue about symlinks too ?

[desimaniac]

Yeah that's true. Any way the permissions on symlinks can also be set - to avoid confusion from others?

[buchdag]

Yes, I'll look into this. Not that hard, but it'll require to use core utils instead of their busybox equivalent.

[desimaniac]

Gotcha. Thx