What exactly is exposed to running container?

[abitrolly]

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?

[trown]

coretoolbox also mounts home into the container:

coretoolbox/src/coretoolbox.rs

Line 434 in 04e3689

static DATADIRS: &[&str] = &["/srv", "/mnt", "/home"];

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.

[abitrolly]

Why /mnt and /srv is there?

Is it possible to mount /home read-only?

Is it also possible to mount only a subset of dirs with copy on write? No private keys. Only certain pubic settings,

[trown]

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.

[abitrolly]

@trown Ruby dev setup that was run in toolbox managed to hose my host user environment by automatically editing config files for my profile. I lost half of the day trying to understand what's going on and another half trying to repair the damage. That's how I lost the trust in the toolbox model.

It can be fixed, though. If writes in HOME outside project dir are made in a separate discardable ostree layer on top of version that existed there before the toolbox container was made.

I do have a command to run command in podman but it doesn't persist the state when I (accidentally) exit, and doesn't allow reentry.

If I knew why ctb mounts specific dirs and what else is going on, I may be able to fork and patch it for my needs instead of learning how to program bash.

[trown]

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 dnf upgrade can hose your system because of the near infinite matrix of packages in linux being impossible to test.

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.