Comment by jonny_eh
2 months ago
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.
18 replies →
This feels like using Docker is just inherently unsafe.
26 replies →
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.
If you're on linux can I encourage people to move to systemd?
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?
Look at the man pages for `machinectl` (then `systemd-nspawn`, `systemd-vmspawn`, and if you want `systemd-portabled`). This is a replacement for docker.
These are container tools offered by systemd.
6 replies →
[dead]