Consider running as root by default

[hairyhenderson]

Originally when we created this image the intent was to keep things "secure by default" by running as a non-root user.

This had its challenges originally - we have to modify the default Caddyfile so that it doesn't try to listen to :80.

However, there has been a certain amount of friction with this approach, since it breaks automatic TLS, and makes usage inside and outside a container considerably different.

For a point of comparison, most other webservers with official images in DockerHub run as root by default.

See also some discussion in Slack for background.

If we decide to run as root, we should also at least document how to run as non-root!

[francislavoie]

Here's some relevant discussion tied into this from the caddy forums: https://caddy.community/t/basic-docker-compose-setup-failing/6892/6

[mholt]

Personally, I am OK with this.

[deakster]

I'm really missing this bit from the original suggestion:

If we decide to run as root, we should also at least document how to run as non-root!

I run 22 containers on my server, for 21 of them I am able to specify the user/group (using PUID/PGID environment variables for example) so that files they produce in their mounted volumes are correct. Caddy is the only one that produces root:root files its data folder.

It would be great if this was an option in this container too. Listening on low ports has never been a problem in containers, since when you map ports in docker they can be different on the host and container (like -p 80:8080). The default could still be root, but having the option to change would be great.

[hairyhenderson]

@deakster you certainly can change, just listen on a port >1024, and run like:

$ docker run --user=12345:12345 -p 80:8080 caddy/caddy ...

It's probably not entirely quite so simple, but that's a start 😉. Could you open a new issue to get this documented more in the README if this isn't enough?

[deakster]

@hairyhenderson Oof, thank you. Guess I never bothered to look into that because of the environment variable options in my other containers (almost all from linuxserver.io).

But the approach above is fine, and the property works fine in docker-compose too.

[hairyhenderson]

@deakster thanks, good to hear!

If you have any other issues or questions, feel free to post them on the forum (https://caddy.community/), or if there are issues with the images specifically go ahead and open a new issue in this repo! 🙂

[westurner]

This is definitely a security regression.

You should not run processes as root (even in containers) if there is an alternative.

That nginx and httpd do it wrong is a poor justification for running as root for convenience. The root user can do anything within the container. A correctly-configured server should not have permissions to change its own config, for example.

• https://americanexpress.io/do-not-run-dockerized-applications-as-root/
• https://www.redhat.com/en/blog/understanding-root-inside-and-outside-container
• Docker now supports rootless mode (for running the docker daemon as non-root)
  https://docs.docker.com/engine/security/rootless/

Running as root should not be the default.

You should never run a frontend webserver as root; regardless of whether the process is running in a container.

[westurner]

From https://medium.com/@mccode/processes-in-containers-should-not-run-as-root-2feae3f0df3b :

Containers are not trust boundaries, so therefore, anything running in a container should be treated with the same consideration as anything running on the host itself.

This comment links to (and quotes) a helpful explanation of what the components of a linux containers do and don't do; in terms of trust boundaries. k3s-io/k3s#1372 (comment)

[hairyhenderson]

@westurner thanks for adding to the conversation, but it's not useful to comment on a closed issue.

Let's carry on the conversation in #104.