-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What exactly is exposed to running container? #13
Comments
coretoolbox also mounts home into the container: coretoolbox/src/coretoolbox.rs Line 434 in 04e3689
It is largely meant to work in a similar way, just in few hundred lines of rust instead of a few thousand lines of bash. |
Why Is it possible to mount Is it also possible to mount only a subset of dirs with copy on write? No private keys. Only certain pubic settings, |
I think you have a different use case in mind then this project or the other toolbox project are trying to solve. The purpose of the toolbox container in both cases is not security isolation. It is assumed everything in the container is trusted. Therefore we mount in everything that is useful (for some definition of useful). I think of the toolbox(and containers more generally) as an extra layer of kernel<->userspace isolation. It kind of makes it more like kernel<->hostOS<->toolbox/flatpak. That extra layer makes it so you don't have to worry about installing a package for development that will hose your host OS. (Or an upgrade to your OS hosing your dev environment.) The toolbox is more like a virtualenv than a virtual machine. If you just want to run a container in the most isolated way possible, it is probably not a very long podman command, since most(all?) options add privileges rather than remove them. The meat of what coretoolbox and toolbox provide is making the CLI behave like the host OS while actually running from a container. |
@trown Ruby dev setup that was run in It can be fixed, though. If writes in HOME outside project dir are made in a separate discardable I do have a command to run command in If I knew why |
Fair enough. I think in the misbehaving ruby case, I would just run that in a regular container with a volume attached for persistence. I more meant the case where something as trusted as Note, I am not the author or even major contributor to either toolbox project. These are only my opinions. I have been using Silverblue for my work laptop for close to a year now though. For a development workstation it is pretty great. |
Major issue with https://github.com/containers/toolbox is that it exposes the whole user HOME to container. How
ctb
is different? Is there a list of its default mounts?The text was updated successfully, but these errors were encountered: