261–270 of 330 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
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
Earlier quoted context omitted.
Podman has lots of underappreciated features, and it's fully open-source!
hmmm, care to tell us a few of them?
Earlier quoted context omitted.
Is it really that much worse than using a package manager that drops a binary that you're not going to inspect anyways?
Yes, it is worse because using your package manager trusts your distribution (and the packages packager), doing curl bash trusts a random website. While in this case docker is not a random website, it's best to use the package manager when available
each package is signed by the person who packages it. That means that if you are pulling from a random place, you can be reasonably sure its the same package because the keys verify.
As pointed out piping curl to bash is problematic. Sure you can go to a browser and check the output, but one of the more fun hacks is detecting if curl pipeing to bash server side and dynamically re-writing the script during serving.
tldr: So long as the package keys are verifiable, you can download a packge from a random mirror and be reasonably sure that it came from who it says it did.
Curl you have no hope, and its possible to infer during execution that you are piping to bash.
Wasn't it well-known that putting people in the docker group is basically the same as giving them root rights?
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.
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.
Earlier quoted context omitted.
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 f…
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.
Conversely, docker containers don't actually exist on MacOs. Docker desktop is merely a way to emulate docker on apple hardware.