6 ms·

> It's also worth noting that caddy is an official image, and as such needs to be similarly-shaped to other official images of the same type. At a quick glance,

by rualca 6y ago

> It's also worth noting that caddy is an official image, and as such needs to be similarly-shaped to other official images of the same type. At a quick glance, none of nginx, traefik, httpd, or haproxy support running as non-root out of the box either. That does not sound like an adequate excuse, does it? I'm afraid none of your remarks makes a reasonable point. Even if you believe that running random stuff as root is ok, if you do not have any reason to do that then why should we mindlessly follow bad practices? If we aim at running a safe system.and there is absolutely zero drawback in following best practices, then why should we continue to make the mistake of intentionally using poor practices?

LucidLynx 6y ago
It is definitely possible to run nginx as non-root in a container: https://www.rockyourcode.com/run-docker-nginx-as-non-root-user/ https://www.rockyourcode.com/run-docker-nginx-as-non-root-us... Also, all the sentences that begin with '>' were comments from https://github.com/caddyserver/caddy-docker/issues/104 https://github.com/caddyserver/caddy-docker/issues/104, and not from the user gbrindisi
- francislavoie 6y ago
  It's also possible to run Caddy in Docker as non-root, but it requires jumping through some hoops when configuring Caddy, for example changing the HTTP and HTTPS ports in global configuration to something else, since those ports are necessary to use for ACME. If the official Docker image did that, then most users would be very confused and we would get lots of support complaints. A cost-benefit analysis told us it was not worth the headache to run as non-root since the Caddy project values highly user experience.
  - cpuguy83 6y ago
    I believe we setup containers in Docker 20.10 such that containers can bind to < 1024 by default without giving it cap_net_bind: https://github.com/moby/moby/pull/41030 https://github.com/moby/moby/pull/41030
saurik 6y ago
To me the argument was pretty simple: if running software as non-root is important--and you clearly think it is--but it is even slightly annoying to write software in a container that doesn't run as root (as maybe it now has to have a special user and internally manage these users; the comment you responded to showed this with de facto evidence) then it seems pretty obvious this shouldn't be an abstraction that people who make containers have to deal with... let them write everything to run as root and then add a damned command line flag to the container runtime to run the container not as root. I don't use containers (I am too deep into security to pretend they are a security boundary and I know too much about toolchains to feel they solve actual deployment problems), so I am frankly shocked this isn't already how they work :(.
- cpuguy83 6y ago
  This is exactly how the work. You either specify the user when creating the container (which can have certain implications, like being able to bind to < port 1024... solveable but still something to deal with) or you can for everything to run with a uid mapping such that uids in the container are mapped to higher uids on the host.
KronisLV 6y ago
But that's the thing - if so many projects are using these bad practices, then doesn't that mean that there's something fishy going on i.e. it's difficult to do things the "proper" way and therefore most people simply don't? Why must we follow these best practices at all - why aren't they simply the default way of doing things, e.g. having to specify a user for the process in the container to run, instead of defaulting to root? For example, look at SSL/TLS certificates - before Let's Encrypt ( https://letsencrypt.org/ https://letsencrypt.org/ ) and tools like either Certbot ( https://certbot.eff.org/ https://certbot.eff.org/ ) or even web servers like Caddy ( https://caddyserver.com/ https://caddyserver.com/ ) which automate both provisioning and renewing certificates, people used to simply run HTTP. But now, it's easier than ever to use them for transport level security, and the stats seem to vaguely back this up, for example: https://www.welivesecurity.com/2018/09/03/majority-worlds-top-websites-https/ https://www.welivesecurity.com/2018/09/03/majority-worlds-to... Why should users inside of containers be any different? What are the factors that prevent safe defaults from being implemented? That's what i don't understand. Disclaimer: i'm not advocating for running things as root, but rather my claim is that if things are hard to do, they simply won't be done unless absolutely necessary. Any tech vendor should acknowledge this and make sure that doing things the "right way" is as easy as possible.
- kortex 6y ago
  I think the fishiness is exactly what your intuition is pointing to: root is easy, "proper" is not. There are very few applications where you need true root at runtime, and most can get by with correctly configured user space. The issue is complexity and lack of appropriate abstractions. The "Let's Encrypt" of dockerfile safety would be something that makes it trivial to 1) create a user 2) chmod/chown an appropriate spot on the fs, 3) ideally let the author defer these actions to always finalize the image in user mode. That way, you declare at the top that you will do these user actions, but RUN stays as root. Or just provide an SRUN, SCOPY,SADD directive which acts like running with sudo. Then, you can easily extend a layer or base image without being concerned with the details of how user space is implemented. Also there is no standard or idiomatic protocol for setting up user space in a dockerfile.
kitd 6y ago
Even if you believe that running random stuff as root is ok, if you do not have any reason to do that then why should we mindlessly follow bad practices? But the argument is, should it be a bad practice?
- rualca 6y ago
  > But the argument is, should it be a bad practice? Are you really asking if running external-facing services as root should be considered a bad practice?
  - kitd 6y ago
    It's a container. The point of Docker is to contain and encapsulate. Lock down Docker. Maybe not a bad practice, but it should be redundant.

by rualca 6y ago

LucidLynx 6y ago

It is definitely possible to run nginx as non-root in a container: https://www.rockyourcode.com/run-docker-nginx-as-non-root-user/ https://www.rockyourcode.com/run-docker-nginx-as-non-root-us... Also, all the sentences that begin with '>' were comments from https://github.com/caddyserver/caddy-docker/issues/104 https://github.com/caddyserver/caddy-docker/issues/104, and not from the user gbrindisi

francislavoie 6y ago
It's also possible to run Caddy in Docker as non-root, but it requires jumping through some hoops when configuring Caddy, for example changing the HTTP and HTTPS ports in global configuration to something else, since those ports are necessary to use for ACME. If the official Docker image did that, then most users would be very confused and we would get lots of support complaints. A cost-benefit analysis told us it was not worth the headache to run as non-root since the Caddy project values highly user experience.
- cpuguy83 6y ago
  I believe we setup containers in Docker 20.10 such that containers can bind to < 1024 by default without giving it cap_net_bind: https://github.com/moby/moby/pull/41030 https://github.com/moby/moby/pull/41030

saurik 6y ago

To me the argument was pretty simple: if running software as non-root is important--and you clearly think it is--but it is even slightly annoying to write software in a container that doesn't run as root (as maybe it now has to have a special user and internally manage these users; the comment you responded to showed this with de facto evidence) then it seems pretty obvious this shouldn't be an abstraction that people who make containers have to deal with... let them write everything to run as root and then add a damned command line flag to the container runtime to run the container not as root. I don't use containers (I am too deep into security to pretend they are a security boundary and I know too much about toolchains to feel they solve actual deployment problems), so I am frankly shocked this isn't already how they work :(.

cpuguy83 6y ago
This is exactly how the work. You either specify the user when creating the container (which can have certain implications, like being able to bind to < port 1024... solveable but still something to deal with) or you can for everything to run with a uid mapping such that uids in the container are mapped to higher uids on the host.

KronisLV 6y ago

But that's the thing - if so many projects are using these bad practices, then doesn't that mean that there's something fishy going on i.e. it's difficult to do things the "proper" way and therefore most people simply don't? Why must we follow these best practices at all - why aren't they simply the default way of doing things, e.g. having to specify a user for the process in the container to run, instead of defaulting to root? For example, look at SSL/TLS certificates - before Let's Encrypt ( https://letsencrypt.org/ https://letsencrypt.org/ ) and tools like either Certbot ( https://certbot.eff.org/ https://certbot.eff.org/ ) or even web servers like Caddy ( https://caddyserver.com/ https://caddyserver.com/ ) which automate both provisioning and renewing certificates, people used to simply run HTTP. But now, it's easier than ever to use them for transport level security, and the stats seem to vaguely back this up, for example: https://www.welivesecurity.com/2018/09/03/majority-worlds-top-websites-https/ https://www.welivesecurity.com/2018/09/03/majority-worlds-to... Why should users inside of containers be any different? What are the factors that prevent safe defaults from being implemented? That's what i don't understand. Disclaimer: i'm not advocating for running things as root, but rather my claim is that if things are hard to do, they simply won't be done unless absolutely necessary. Any tech vendor should acknowledge this and make sure that doing things the "right way" is as easy as possible.

kortex 6y ago
I think the fishiness is exactly what your intuition is pointing to: root is easy, "proper" is not. There are very few applications where you need true root at runtime, and most can get by with correctly configured user space. The issue is complexity and lack of appropriate abstractions. The "Let's Encrypt" of dockerfile safety would be something that makes it trivial to 1) create a user 2) chmod/chown an appropriate spot on the fs, 3) ideally let the author defer these actions to always finalize the image in user mode. That way, you declare at the top that you will do these user actions, but RUN stays as root. Or just provide an SRUN, SCOPY,SADD directive which acts like running with sudo. Then, you can easily extend a layer or base image without being concerned with the details of how user space is implemented. Also there is no standard or idiomatic protocol for setting up user space in a dockerfile.

kitd 6y ago

Even if you believe that running random stuff as root is ok, if you do not have any reason to do that then why should we mindlessly follow bad practices? But the argument is, should it be a bad practice?

rualca 6y ago
> But the argument is, should it be a bad practice? Are you really asking if running external-facing services as root should be considered a bad practice?
- kitd 6y ago
  It's a container. The point of Docker is to contain and encapsulate. Lock down Docker. Maybe not a bad practice, but it should be redundant.