Every time I try to install Docker there's a warning that being in the "docker" group is equivalent to having root access.
You should probably know about this workaround by now.
back
9 comments
Most of us install Docker just to run a project locally, and is part of a long checklist of things to install. We can't expect everyone to be an expert on the hundreds of apps/tools/packages that get installed on a machine. It's like expected people to read, and understand, all the terms of service shoved in front of us on a daily basis.
That's why adding your user account to the docker group is a separate step that explicitly does not happen as part of the installation: https://docs.docker.com/engine/install/linux-postinstall/
> Warning
> The docker group grants root-level privileges to the user. For details on how this impacts security in your system, see Docker Daemon Attack Surface.
wait so just being lazy and using sudo on Docker commands instead of figuring things out actually means I'm being safer? awesome.
No, because a malicious AI agent could just replace the sudo binary in your path with one that collects your password and uses it to execute arbitrary code as root. Nothing short of sandboxing everything or just never using AI agents or proprietary software will prevent this.
This feels like using Docker is just inherently unsafe.
funily less is often more in security while ur devving. but its best to be aware rather than lucky :p
Well in 2026 most likely this step was also done by an agent with --dangerously-skip-permissions
And containers were supposed to make things safer ...
Huge design mistake if you ask me.
i don't see how it's a design mistake, linux allows more footguns in general to not decrease utility. Allowing you to manually give root prompt access (with warnings!) to a non-root user is one of them.
you can also just not run docker as root and not add normal users to the docker group
> And containers were supposed to make things safer ...
No. Containers are a slight improvement over the .tar.gz software distribution method we had a few decades ago.
(And I mean "slight" literally - a Docker container is just a .tar.gz with a bundled bash script that runs in a chroot.)
Containers were never a security boundary
That's true, the majority of people probably install software without much thinking; but it's also true that it's always better to have at least some high level understanding how the specific piece of software works. What access the given software has, will it send something over the network or work locally; that kind of stuff.
As for Docker, I would assume everyone who ever tried to bind-mount a volume for writing from inside the container (on Linux*) then were surprised to see root-owned files in their bind-mounted directory. For me personally, that was the moment I realized that containers, by default, have root access to the filesystem. No written warning serves better than the need to chown some root-owned files.
* Not on macOS. On macOS Docker basically runs in a VM, and there's no root access to the host filesystem from what I understand.
[edit: formatting]
Docker relies fundamentally on the Linux kernel. Since macOS does not have a Linux kernel, you have to run Linux in a VM first and then run Docker on top of that.
So, you may get filesystem access inside the VM. Breaking out of the VM may be a different matter.
Precisely. There is nothing preventing you from doing the same in Linux: rather than installing docker, install docker on a Linux VM (ie. using KVM).
Conversely, docker containers don't actually exist on MacOs. Docker desktop is merely a way to emulate docker on apple hardware.
I primarily use Incus for all container stuff, not Docker. Is problematic if I want to e.g. use a docker-compose file, but I (think) it protects against these things because incus allows me to create a vm and not a container if I really need that level of isolation.
What's the downvote for? Does someone really dislike Incus that bad?
Most people buy scissors just to cut some paper. We can't expect everyone to recognize that they are sharp.
To be fair, I struggled since forever to understand this root group thing and didnt bother to add to docker group. This workaround give me a better understanding, like seeing someone cut themselves on a scissor
The very basic thing about software engineering is to know what the f you're using to build your project. You don't need to be an expert but if you're blindly installing whatever you want on your machine from a "checklist of things to install" without absolutely having no idea what the things being installed are, it is 100% on you. You don't need to be an "expert" to understand this, you need to be "somewhat competent," and that is a very low baseline tbh.
If you’re a software engineer then yes, I can and do expect you to understand all that.
> Most of us install Docker just to run a project locally
There's your mistake.
(Akshually using Docker is the real mistake, but that ship has sailed, no fixing these people now.)
Man no wonder ai wows a lot of HN posters. This can't be the default attitude of developers today.
no its not. its like expecting people to know how car work before trying to drive it.
not reading terms might see copyright being broken.
not reading manuals and warnings will get all your livelihood stolen by hackers.
different ballgame different focus.
> Most of us install Docker just to run a project locally
I'll admit, systemd is a bit more annoying, but the main annoyance is that there aren't the pre-built images that you can just set and go. That same capability exists with systemd (via `importctl` and `machined`), but those configurations don't already exist. But on the plus side, I've been working with systemd since pre-LLM days and I feel that they are pretty good at dealing with these configurations[0]. Now, with that out of the way...
Systemd already is working with your OS. So you get nice things like virtual machines (`systemd-vmspawn`), containers (`systemd-nspawn`), and portables[1] (`systemd-portabled`) (not to mention `homed`!). I've found these to be fairly easy to setup and quite natural if you're already used to the linux ecosystem. I've never been great at docker, but these have felt much more natural to me. So different strokes for different folks. There's definitely a learning curve, but that's also true for docker or any other container system. Importantly, I find security easier to handle with systemd because I can use `systemd-analyze` and the control settings are almost identical across VMs, spawns, and portables. So makes for less learning and greater control.
Definitely not for everybody, but I think is also a tool that's underappreciated.
[0] And I don't feel this way about bash scripting! The advantage here is that these systemd configuration files are fairly boilerplate. Enough that I stash templates in my dotfiles and copy paste them when I build new services, timers, machines, whatever. So perfect type of LLM task. 90% of the time. But hey, we're also on HN and I'm talking to the nerds. Systemd isn't for everyone
[1] https://systemd.io/PORTABLE_SERVICES/ also see https://github.com/systemd/portable-walkthrough Portables are actually often what people want with what they're doing with docker.
EDIT: I very frequently will spawn a machine to run a program that's on a different base distro. Not because I can't run/don't know how to run debs or rpms on arch based distros (I do), but because frankly, it is often easier to just spawn a container after I've already made the first image (cloning images is trivial).
I too have learnt to like systemd.
But what is the relevance here? In what way is it a replacement for docker?
I recently switched over to podman and it's been great!
Podman on Windows - never been able to fully get rid of it and it throws errors on boot after uninstall. Was a fan, am now not.
Good to know, I'm on Linux, switching our dev/stg/prod servers over to it partly because we had all this workaround mechanics in place so that "apt update" updating docker packages wouldn't restart services (we typically don't rotate machines out of the load for just an apt update). Podman + quadlets conversion was not terribly hard, and has eliminated this issue.
Don't use Windows
A lot of us don’t get a choice.
> My """ai""" just did something amazing, click to learn more
99% of the time it just read the man or some other form of documentation
Given how few people read documentation, that's still pretty amazing
Given that someone wrote this up directly as a recipe for agents to follow, and put it on the WWW where it has been scraped many times since 2025 no doubt, it's not that amazing.
Install docker (systemd daemon) in a separate rootless Linux namespace (user). I wrote this down here [1]. Zero trust & separation of concerns.
[1]: https://du.nkel.dev/blog/2023-12-12_mastodon-docker-rootless...
There are lots of ways to get root on a typical Linux developer workstation, the point is that agents shouldn't be using any of them unprompted.
This. I am running Claude in its own QEMU VM, it has git access to my project only if I explicitly unlock the ssh key for it. The other day I realized it trying to push a change, it didn't have permission, so it went looking for "workarounds" and found I had a github cli session and tried to use that, luckily the creds for that was also read scoped. But the point is, if I did not give permission and it sees I did not give permission, it should not try to find a workaround/exploit autonomously.
> I am running Claude in its own QEMU VM
How much system resources does it need to work smoothly? I was also thinking about doing something similar.
This is incredibly ironic considering it's a sandboxing technology
This is why I have never really liked docker, apparently Podman is drop-in capable for docker without the root requirements on the other hand.
I think that's distro-specific. Some set it up with more secure defaults (unix socket with permissions), others less (TCP socket).
I don't really know of any distro that doesn't do that. All of Docker Inc. default installs and all of distros I know of don't automatically add you to the docker group. docker.com instructions has the infamous "linux post-install instructions" that explain and walk you though it.
The tragedy is of course that when security and usability collide, 80/20 rule will apply where 80% of people will pick usability over security. I have worked with many with the title >= "Senior Engineers" who saw that page, read the explanation, and still had no idea what the ramifications of their changes were. "Yeah sure it said any user in the docker group will be able to get root on the host, but aren't containers isolated?"
That’s the mental model that works for people, specifically those that come from VM workflow.
Ironically that’s how Docker works on every platform where it’s running a non-native OS. On macOS that’s how all images are run. Linux on Linux is the only Docker combination that is particularly problematic from a security perspective.
Virtualisation has advanced greatly since docker was introduced, if your running in local hardware that’s supports virtualisation, Docker should be running images fully virtualised. There is no good reason to use the OS kernel for most use cases as the performance impact is negligible. If you need kernel access there are better options, like systemd containers.
No, docker access means root.
You can use "rootless" mode, in this case it means root in a user namespace (that is not the "host" user namespace).
That's not relevant. If you have access to the Docker daemon running as root, whether it's over a Unix socket or a TCP socket, you effectively have root.
That, in a nutshell, is why I do not install Docker