> 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.
Huge design mistake if you ask me.
you can also just not run docker as root and not add normal users to the docker group
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.)
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!
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.
`/usr/bin/sudo`?
$ which() { echo foo; }
$ \which
foo
`command which` wouldn't have been the built-in
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.
Containers don't provide good isolation and tend to be trivial to break out of.
I think not, virtualization has such low overhead now that there's just no excuse. It's generally trivial to switch from containers to VMs.
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.
> 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.
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.
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]
So, you may get filesystem access inside the VM. Breaking out of the VM may be a different matter.
Conversely, docker containers don't actually exist on MacOs. Docker desktop is merely a way to emulate docker on apple hardware.
There's your mistake.
(Akshually using Docker is the real mistake, but that ship has sailed, no fixing these people now.)
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).
But what is the relevance here? In what way is it a replacement for docker?
> In what way is it a replacement for docker?
These are container tools offered by systemd.