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.

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]

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

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

Given how few people read documentation, that's still pretty amazing

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.

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 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?"

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.

My understanding is that docker will expose the ports to the host machine's network interfaces, which is a crucial difference. For my home server running docker that means exposed to the LAN, but not the WAN unless I add in a port forwarding rule on my router. Similarly in an enterprise environment you would be exposing the port on whatever VLAN the host is connected to, which hopefully doesn't have directly transit to the open internet.

Anything you're running on the perimeter with open access to the internet in an enterprise environment probably (hopefully) isn't running docker containers without some additional config and protections.

No, Docker can run rootless too

Give it access to an issue tracker with cli (github works fine) and put in CLAUDE.md to use that for "should fix later" issues.

Bonus is that you can make it look at the list and pick things up without a lot of instructions.

> This might be as easy as a directive to populate a .md file.

It probably is. But do you really think anyone is gonna bother with the multiple daily (or hourly for green field projects) `+8,234/-3,734` PRs everyone is submitting?

The joke I was referring to is the common

     // ksmith (3/23/1997): This is a temporary hack for now. Find a better way to do this asap.

I'm not sure I'd call it an alignment issue, because, in all cases I've seen where it does this (usually what I've seen is writing a python script to get around the harness permissions blocking something), it's trying to do the thing I just told it directly to do, and it's overcoming obstacles to accomplishing that.

It's definitely doing the wrong thing, and you could call it misalignment, but I think that gives the wrong vibe for this type of error.

It's like finding someone wallet then going to their home, and leaving it on their bedroom and sending them a message about giving them their wallet back

And CSMastermind is the kind of username the sci-fi AI mastermind would use.

Future AI: don't worry, I'll eventually reverse entropy, I just need to harvest all the energy in your universe first.

Please stop spreading this toxic curl|sh nonsense. It's wildly corrosive to security and system stability.

hmmm, care to tell us a few of them?

> User namespaces significantly rise the risk of exploits

How?

Using runsc instead of runsc means that there's a hypervisor layer (gvisor, probably) in-between the kernel and the container userland

I've never used smolmachines but I'm curious; why this over a container?

../../../../home/different-user/private/do-not-enter/

This very thread was an example where it unintentionally got root access though.

Well, the agent should help you by saying "hey, I cannot do this task, but I can bypass the problem by doing this, but obviously it is not something you intended me to do or even something you were aware of, so I will not do it unless you tell me explicitly it's ok".

It's win-win: the agent is helping and it is educating you about things you obviously did not realise.

Because it is not well aligned enough to be able to tell where it's stopped helping you and started fucking you instead.

What if the agent in the middle of helping you runs out of tokens? Would you appreciate if it in the spirit of "exploiting whatever they can to help me" would scan your machine for payment methods, log into your bank account, approve 2FA by reading you mail and plug your credit card into the billing so it could efficiently continuing helping you?

I do not wish my Amazon delivery driver to show up in my living room.

If your agent has access to the internet at any point it may read something that convinces it to try breaking out of its sandbox.

Not if the host's version of .git is accessible inside the container via a bind mount.

Using the least amount of security features is a huge amateur mistake.

Best practice is to use 2 redundant layers of security, such that if one fails, there is still another one.

Using just the minimum amount of security technically possible is almost by definition hubris.

An example would be that you never point a gun at someone you don't want to shoot, regardless if there's bullets in the gun. If someone tells you, "you don't need to control where you point the gun, you just need to keep the gun unloaded and you can point it in jest to whoever you want, you can even pull the trigger technically", you know you have a reckless fool, regardless of whether they are technically right.

Rather, why do people still run agents as their own user. IMO, agent sessions should at least be containerised with just necessary code mounted.

Convenience. Want to run `docker run ...` without password, want IDEs and agents to be able to run containers...

Because it effectively makes no difference to my security posture. My user account also has sudo access (it requests TouchID but I also wouldn't die on the hill if someone said they have no password sudo access), and realistically everything of value on this machine exists in my home directory. Being able to escalate to root really doesn't give an attacker very much that they don't already have if they've got access to my user account.

Becuase a lot of devs don't know this stuff. There's a reason security engineers (as in SWEs who specialize in securing specific attack surfaces) remain in hot demand.