[jonny_eh]

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.

[Ajedi32]

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.

[HeWhoLurksLate]

wait so just being lazy and using sudo on Docker commands instead of figuring things out actually means I'm being safer? awesome.

[NotPractical]

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.

[gopher_space]

Once I noticed that models will treat lack of superuser access as an obstacle I moved all of the agent crap to its own machine. Watching some mid-tier offering chain together tools like its a gorilla escaping the zoo and I'm just not going to deal with that situation.

[overfeed]

I'm more worried about my `~/.aws` and `~/.ssh` folders. People who use IDE-based AI tooling with IDEs that support dev-containers have no excuse for not leveraging dev containers, both for preventing agents losing your data and defending against secrets-harvesting supply-chain attacks

[l23k4]

Using containers as a security boundary is inexcusable.

[sersi]

It's why all of my agent run in a vm. I refuse to have it run on my own machine. Claude code once managed to render the vm unbootable, I was back in action 5 minutes later after regenerating the vm

[mancerayder]

What were you trying to tell it to do?

I recently took the risk there by having it run xattr commands to fix some MacOS bug with Tahoe that broke auto update for what seems like all software.

[lucaspiller]

My agent has access to my email, my messages, my work, my finances, my life. But thank god it doesn't have access to root on my machine.

[mmh0000]

As always. XKCD: https://xkcd.com/1200/

[latexr]

> Nothing short of sandboxing everything or just never using AI agents or proprietary software will prevent this.

Using open-source (non-proprietary) software won’t necessarily save you either. XZ is open-source and it was basically dumb luck that we weren’t all infected. Same with the myriad exploits to NPM.

[shevy-java]

Ok but in this case the problem wasn't the AI agent - the AI agent merely took advantage of this prior problem in the first place. For instance, if docker group were not superuser-like, that issue could not have happened.

> Nothing short of sandboxing everything or just never using AI agents

But the problem was not the AI agent.

Sandboxing is quite neat though; I remember on GoboLinux the idea of AlienFS to have every application run in a sandboxed manner, so it would only see other programs it needs, but never more than that. I consider it a better engineering focus to have this as minimal layer, even outside of security-related concerns.

[dark-star]

If malicious AI has replaced the sudo binary, then it can already run arbitrary code as root. No need to "collect your password" then

[ikurei]

It could just alias sudo on your ~/.bashrc. No need to replace the actual file on /usr/bin/sudo or wherever you have it. I would only need to be able to run arbitrary code as you.

[smegger001]

Sigh. What ever happened to the principle of least privilege and why arent we applying it to AI agents. They ought to be locked in a box and not capable to act outside designated task.

[SpaceNoodled]

This feels like using Docker is just inherently unsafe.

[LeFantome]

The fact that Docker is unsafe was one of the core motivations for Podman.

[Leynos]

Was gonna say, "why not podman?"

[hgomersall]

No, using AI tools not in an effective sandbox is inherently unsafe.

[cassianoleal]

Both can be true.

[vitally3643]

Yes, that's why they warn you about it.

[dymk]

That’s what rootless docker is for

[antonkochubey]

rootless docker's networking (slirp4netns) is still terribly buggy and in edge cases often locks up using 100% CPU until you discover that your laptop is a lapwarmer and kill it

[Helmut10001]

I found it pretty reliable and use it across all my docker projects, development and production.

[itintheory]

This feels like using sudo is just inherently unsafe.

[gruez]

This but unironically. There's no way to ensure that nobody overwrote your .profile or .bashrc with a backdoored sudo that steals your password, or runs your command and then runs an evil command afterwards.

[zahlman]

`which sudo`?

`/usr/bin/sudo`?

[jjmarr]

It is. That's why SELinux and AppArmor were invented.

Instead of having "root" and "user", both of these provide sets of permissions that can be granted to apps.

In this case, SELinux would've stopped this. Codex could've still relabelled the files when mounting but this can be blocked for sensitive directories like /etc.

[alsetmusic]

This feels like using a computer is inherently unsafe.

On the plus side, once we outlaw them we'll shut down the ability for conspiratorial thinking to spread easily and the world will slowly heal from the last couple of decades (the previous one in particular).

Hooray! We're finally doing something about the harms of social media. Smash your computer today!

[LeFantome]

Safety meeting. Nobody works, nobody gets hurt.

[DANmode]

Ah yes, it’s the conspiratorial thinking dividing society,

not humans being humans,

not the people at the highest echelons of society being corrupt (Epstein called).

It’s the people trying to piece that evil together so they know what to tell their kids - they’re the problem.

Sure.

[b65e8bee43c2ed0]

I think we're only a few decades away from these things being said unironically.

[saidnooneever]

funily less is often more in security while ur devving. but its best to be aware rather than lucky :p

[jatins]

Well in 2026 most likely this step was also done by an agent with --dangerously-skip-permissions

[amelius]

And containers were supposed to make things safer ...

Huge design mistake if you ask me.

[twelvedogs]

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

[otabdeveloper4]

> 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.)

[halfcat]

Containers were never a security boundary

[ventana]

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]

[LeFantome]

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.

[repelsteeltje]

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.

[ethin]

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.

[ethin]

What's the downvote for? Does someone really dislike Incus that bad?

[aftbit]

Most people buy scissors just to cut some paper. We can't expect everyone to recognize that they are sharp.

[vdfs]

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

[altmanaltman]

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.

[LaGrange]

If you’re a software engineer then yes, I can and do expect you to understand all that.

[otabdeveloper4]

> 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.)

[noobermin]

Man no wonder ai wows a lot of HN posters. This can't be the default attitude of developers today.

[saidnooneever]

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.

[godelski]

  > Most of us install Docker just to run a project locally

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).

[worik]

I too have learnt to like systemd.

But what is the relevance here? In what way is it a replacement for docker?

[godelski]

  > 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.

[MrDrMcCoy]

The problem is that the tooling for creating, importing, and managing images is not as good with systemd vs Podman/Docker. There's also no clear path to import images from the Docker ecosystem, at least as far as user experience goes. I know how to do it, but the number of extra steps involved always drives me back to Podman.

[godelski]

I don't really find them that bad but I'm still going to maintain my "different strokes for different folks" position. Might be bad for you and good for others. More options isn't a bad thing

[curt15]

The systemd suite of container tools treat containers like mini VMs and expect a full init system. They are not designed for ephemeral single-process app containers like docker containers.

[godelski]

I think you only looked at nspawns. Check out the other two

[ciupicri]

podman is supposedly a replacement for docker.

[godelski]

There's plenty of container technologies and I'd be happy to see more of them used. Podman isn't for me, but it is a great option for others. Regardless, I think it is relatively unknown that systemd can be used for creating containers.