>Why doesn't docker respect unix filesystem permissions? I use docker on a shared server, i can delete docker images of other users. This is bonkers.

Same reason a Postgres root can delete tables of other users.

It could, but it would be a shim on top of Docker to respect them.

Docker is a service daemon running as root, and the images of other users are just entries created by the other users in its registry, not server files that have permissions of each user.

When you're creating a new docker image, you just send a command to that daemon process - you're not passing your user account credentials to create. As far as docker is concerned, it's just one more image it knows, not an image belonging to you specifically.

▲

enriquto 19 hours ago | parent [-]

I understand the mechanism. I wanted to know the reasons for this choice.

Why choose to break user boundaries? Why can't docker images be files in the possession of each user?

	▲	coldtea 18 hours ago \| parent \| next [-]
		They didn't chose to break user boundaries. They chose not to artificially recreate them. In the shared daemon model, there are no user boundaries. Even if the files belonged to each user permissions-wise, the central daemon running as root would be able to edit all.
	▲	zbentley 13 hours ago \| parent \| prev [-]
		I think there's two questions there: Q: Why not have container builds and runs be invoking-user-specific by default? A: As the adjacent commenter pointed out, this would be an overlay on fundamentally rootful behavior. It would also remove a lot of "works on my machine, works anywhere", since different user accounts running/building containers could be restricted in different ways on different computers, so my "docker build" and your "docker build" might both work, but do different things or fail in different ways. Note that this isn't the same as saying "rootful dockerd is good"; it's not (usually)! That's why rootless docker (https://docs.docker.com/engine/security/rootless/) is recommended in many environments. But even in rootless, the run-user of the container and build are still uniform with the rootful behavior (albeit they require more participation from the daemon-owning user account WRT UID mapping/user namespaces/privileged actions), which I think is a good thing. Rootless docker, last I used it, behaved sensibly re: vs. user container images (kept per-user) and globally-cached layers (removable by anyone), but that may have been a specific configuration where I was using it. Q: Why aren't docker images user-browsable files? A: I can't say for sure; I didn't build Docker, but I hear the guy who did is in the neighborhood :). I suspect it's a combination of caching (since build stanzas/Dockerfile lines are intended to be proxies for the content address of a layer, there's nothing to gain by making layer caches per-user), implementation convenience, and an influence from the Golang platform wherein (after the age of vendoring wound down) the developer tooling has many convenience layers that de-emphasize user visibility of build/download artifacts a la "go run". Docker goes further, though. And yes, I know that you can get at OCI images/layers as files. But most people don't.