[otabdeveloper4]

You misunderstand how it is in the wild. Much (most?) of the time Docker and docker-compose are used to package big-ball-of-legacy-mud applications and their dependencies and push them out on the unsuspecting world. Installation instructions for most web app software today is "here, download and run this docker-compose.yml".

Of course nobody vets or even looks at the mess inside the compose file, and most of this software won't even run without root privileges. (Because it hooks into various system bits and violates all sorts of isolation rules.)

People value Docker as a packaging tool; especially as a go-to tool for packaging legacy crap and software-as-a-pet systems.

Running this stuff without any sort of checking and as root is bonkers, but it is what it is.

We're kind of back in the Windows 95 era of packaging software as far as server backends go. Maybe it will change after some very serious worms and viruses his the Docker ecosystem. (Windows changed very slowly and only after tremendous pressure from cybercrime.)

[throwaway894345]

> Installation instructions for most web app software today is "here, download and run this docker-compose.yml".

Plenty of software is distributed as "copy/paste `curl ... | sh`" or "npm install ..." or "pip install ...". This is absolutely not unique to containers.

> most of this software won't even run without root privileges

I don't buy this at all. The container runtime probably needs root privileges, but individual containers rarely need privileged access. Moreover, in many (all?) cases we can use security policies to prevent root containers by default.

> Running this stuff without any sort of checking and as root is bonkers, but it is what it is.

Again, true of any software, containerized or not. For what it's worth, I'm pretty sure people are more likely to inspect a docker-compose.yml than they are to decompile an ELF binary.

> We're kind of back in the Windows 95 era of packaging software as far as server backends go. Maybe it will change after some very serious worms and viruses his the Docker ecosystem.

We've always been in that era. The only difference is that today our systems are designed with more security in mind.

[otabdeveloper4]

> I don't buy this at all. The container runtime probably needs root privileges, but individual containers rarely need privileged access. Moreover, in many (all?) cases we can use security policies to prevent root containers by default.

Ha, little do you know. It's common to bind-mount various system directories or UNIX sockets into the container. Also, does it matter when you're running a full OS inside the container anyways?

Hosting providers is a tiny slice of the pie, most Docker users are simple end-users looking to run random internet software. (E.g., Docker is the only way to install third-party software on LibreELEC, a simple media center OS for the living room TV.)

[throwaway894345]

> It's common to bind-mount various system directories or UNIX sockets into the container.

it’s not that common, in production systems anyway.

> Also, does it matter when you're running a full OS inside the container anyways?

Containers famously don’t include an operating system. They use the host’s kernel.

> Hosting providers is a tiny slice of the pie, most Docker users are simple end-users looking to run random internet software. (E.g., Docker is the only way to install third-party software on LibreELEC, a simple media center OS for the living room TV.)

I don’t believe this is true. I would wager that the overwhelming majority of containers are running in the cloud or in data centers.

[morelisp]

> It's common to bind-mount various system directories or UNIX sockets into the container.

Sometimes I feel bad about our security posture and then I read stuff like this. Thanks.

[johnchristopher]

> Of course nobody vets or even looks at the mess inside the compose file, and most of this software won't even run without root privileges. (Because it hooks into various system bits and violates all sorts of isolation rules.)

I don't know about that. I recently was tasked with installing a web service, running in a container.

First thing I noticed was that the container was bundling a nginx reverse proxy, a node js server, a redis database, a rabbit-mq service and a pgsql database. I noticed because after installing the whole thing I wondered why the database was working fine even when the env variables for the pgsql were wrong. Those env variables are in the README (along with other variables holding secrets so it's not clear what is necessary and what is not from reading the documentation).

Then trying to proxying the thing I, after an afternoon of banging my head, I remembered docker has an impact on iptables rules. The documentation and support forums mixes both nginx as the reverse proxy/frontend running inside the container and nginx running in front of it.

So, documentation was not good and I don't see how anyone downloading this docker-compose.yml file would be able to run it without digging through it but it doesn't mean a well documented shipped docker bundle with 1 process per container is hard or impossible or not desirable.

I do agree that the tendency of some projects to ship a docker-compose.yml with one service running multiple processes (databases, server, proxy, cache, etc.) is a giant PITA. I mostly see that from opensource projects with a paid enterprise version. I am pretty sure it's never the bundle they are actually running in production.

Now, when I read some `sudo docker` I think the same things that I think when I read `sudo pip install`.

[Art9681]

This is a process problem. The wild is exactly that, a place to experiment and learn and iterate and fail. In any professional organization, all of your concerns can be adressed with the proper talent and tooling.