6 ms·

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

by jjmarr 5mo ago

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.

Youden 5mo ago
I think that's distro-specific. Some set it up with more secure defaults (unix socket with permissions), others less (TCP socket).
- cpuguy83 5mo ago
  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).
- eddythompson80 5mo ago
  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?"
  - fps-hero 5mo ago
    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.
    - eddythompson80 5mo ago
      I agree that virtualization has seen great advances. Kata containers on k8s are almost (not quite 100%) drop in replacement. Regardless those last 10% remain a problem. I run a personal server for few open source applications for personal use. I was thinking with all the supply chain attacks, and how carelessly I run `docker pull`s to update things I should probably consider hardening things a bit. I thought before jumping to full virtualization with Kata I can easily try gvisor/runsc first. Only to realize that DNS resolution is completely different with runsc vs runc and had to switch back. Another sticking issue with virtualization is resource allocation. With namespace docker you can easily oversubscribe each container CPU/memory and rely on the single kernel letting individual containers burst as needed. With full virtualization this is still a big problem. Even with balloon devices and dynamic memory and CPU etc, the resource allocation is still not optimal. On a basic 8 core/16GB machine you can run 1 or 2 dozen services and things generally workout fine. Trying to run each of those in a virtualized VM you suddly can maybe run 6 or 7 maybe. There is no way to tell VM 3 kernel to drop its file system cache because VM 6 needs to load a large file in memory. Even if you script it out, now VM 3 is slow because it dropped all its cache while VM 6 finished processing 3 hours ago. These are not unsolvable problems, but despite how far virtualization has come, are still friction points. Not to mention issues like sharing hardware devices (GPUs, disks, USB devices etc) between multiple VMs
- isityettime 5mo ago
  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.
linsomniac 5mo ago
I recently switched over to podman and it's been great!
- anakaine 5mo ago
  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.
  - linsomniac 5mo ago
    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.
  - Zardoz84 5mo ago
    Don't use Windows
    - moomin 5mo ago
      A lot of us don’t get a choice.
      - worik 5mo ago
        > don't use windows > A lot of us don’t get a choice Wise advice and facts... the terrible state of our industry
      - sieabahlpark 5mo ago
        [dead]
      - brianwawok 5mo ago
        Sure you do.
jonny_eh 5mo 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.
- ventana 5mo ago
  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]
  - ethin 5mo ago
    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 4mo ago
      What's the downvote for? Does someone really dislike Incus that bad?
  - LeFantome 5mo ago
    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.
toasty228 5mo ago
> 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
- readthenotes1 5mo ago
  Given how few people read documentation, that's still pretty amazing
  - JdeBP 4mo ago
    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. * https://news.ycombinator.com/item?id=48350964 https://news.ycombinator.com/item?id=48350964
worik 5mo ago
That, in a nutshell, is why I do not install Docker
deleted 5mo ago
[deleted]
Retr0id 5mo ago
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.
- anygivnthursday 5mo ago
  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.
  - fransje26 4mo ago
    > 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.
    - anygivnthursday 4mo ago
      I dont think Claude itself needs much, its more like what you do with it. In my case it is doing some gradle builds and java tests with some postgres docker containers inside the vm so I gave it max 8G RAM with 4 cores and have no issues. I share my workspace folder (with virtiofs and also the user home so I can rebuild the vm from scratch and keep settings) because I like my tools on the host and my full creds are outside and I didnt want to keep syncing branches. I access it with ssh (with passt). So far no real issues.
      - anygivnthursday 4mo ago
        Late edit, I wanted to clarify I do not share my user home, but the VM user home for backups, thats separate user that does not have my own users credentials etc
Helmut10001 4mo ago
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/ https://du.nkel.dev/blog/2023-12-12_mastodon-docker-rootless...
giancarlostoro 4mo ago
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.
indianrestrooms 4mo ago
[flagged]
torginus 4mo ago
This is incredibly ironic considering it's a sandboxing technology

by jjmarr 5mo ago

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.

Youden 5mo ago

I think that's distro-specific. Some set it up with more secure defaults (unix socket with permissions), others less (TCP socket).

cpuguy83 5mo ago
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).
eddythompson80 5mo ago
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?"
- fps-hero 5mo ago
  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.
  - eddythompson80 5mo ago
    I agree that virtualization has seen great advances. Kata containers on k8s are almost (not quite 100%) drop in replacement. Regardless those last 10% remain a problem. I run a personal server for few open source applications for personal use. I was thinking with all the supply chain attacks, and how carelessly I run `docker pull`s to update things I should probably consider hardening things a bit. I thought before jumping to full virtualization with Kata I can easily try gvisor/runsc first. Only to realize that DNS resolution is completely different with runsc vs runc and had to switch back. Another sticking issue with virtualization is resource allocation. With namespace docker you can easily oversubscribe each container CPU/memory and rely on the single kernel letting individual containers burst as needed. With full virtualization this is still a big problem. Even with balloon devices and dynamic memory and CPU etc, the resource allocation is still not optimal. On a basic 8 core/16GB machine you can run 1 or 2 dozen services and things generally workout fine. Trying to run each of those in a virtualized VM you suddly can maybe run 6 or 7 maybe. There is no way to tell VM 3 kernel to drop its file system cache because VM 6 needs to load a large file in memory. Even if you script it out, now VM 3 is slow because it dropped all its cache while VM 6 finished processing 3 hours ago. These are not unsolvable problems, but despite how far virtualization has come, are still friction points. Not to mention issues like sharing hardware devices (GPUs, disks, USB devices etc) between multiple VMs
isityettime 5mo ago
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.

linsomniac 5mo ago

I recently switched over to podman and it's been great!

anakaine 5mo ago
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.
- linsomniac 5mo ago
  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.
- Zardoz84 5mo ago
  Don't use Windows
  - moomin 5mo ago
    A lot of us don’t get a choice.
    - worik 5mo ago
      > don't use windows > A lot of us don’t get a choice Wise advice and facts... the terrible state of our industry
    - sieabahlpark 5mo ago
      [dead]
    - brianwawok 5mo ago
      Sure you do.

jonny_eh 5mo 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.

ventana 5mo ago
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]
- ethin 5mo ago
  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 4mo ago
    What's the downvote for? Does someone really dislike Incus that bad?
- LeFantome 5mo ago
  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.

toasty228 5mo ago

> 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

readthenotes1 5mo ago
Given how few people read documentation, that's still pretty amazing
- JdeBP 4mo ago
  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. * https://news.ycombinator.com/item?id=48350964 https://news.ycombinator.com/item?id=48350964

worik 5mo ago

That, in a nutshell, is why I do not install Docker

deleted 5mo ago

[deleted]

Retr0id 5mo ago

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.

anygivnthursday 5mo ago
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.
- fransje26 4mo ago
  > 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.
  - anygivnthursday 4mo ago
    I dont think Claude itself needs much, its more like what you do with it. In my case it is doing some gradle builds and java tests with some postgres docker containers inside the vm so I gave it max 8G RAM with 4 cores and have no issues. I share my workspace folder (with virtiofs and also the user home so I can rebuild the vm from scratch and keep settings) because I like my tools on the host and my full creds are outside and I didnt want to keep syncing branches. I access it with ssh (with passt). So far no real issues.
    - anygivnthursday 4mo ago
      Late edit, I wanted to clarify I do not share my user home, but the VM user home for backups, thats separate user that does not have my own users credentials etc

Helmut10001 4mo ago

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/ https://du.nkel.dev/blog/2023-12-12_mastodon-docker-rootless...

giancarlostoro 4mo ago

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.

indianrestrooms 4mo ago

[flagged]

torginus 4mo ago

This is incredibly ironic considering it's a sandboxing technology