toolbox is unsafe

[abitrolly]

In #389 I discovered that I can write files outside the toolbox. Today I tried to install RVM inside the toolbox and instead messed with my dotfiles. That's why I want to raise this issue as critical.

Containers are protecting the developer from running code that potentially can destroy the system. But because developers already work under unprivileged user, the protection that container provides is only about isolating developer's files. toolbox container exposes everything. My private keys are readable from inside of container, $HOME is writable to it, and programs installed into the container (like RVM) will modify your host dotfiles. Until this is fixed, this is big no-go for me.

toolbox brought an interesting concept that it is possible to restart previous container, so I will continue to use something simple, like

#!/bin/bash
NAME=$(basename "$PWD")

podman run -v "$(pwd):/root/$NAME":Z -w "/root/$NAME" -it "$@"

Maybe only find a way to find and reexec container if it already exists.

[bkhl]

I'm also bothered by this for my development containers.

For now, what I've done is build my own development containers, that among other things override various environment variables to make the development tools put their files somewhere else in /var/ in the container, rather than in my home directory.

As an example, in this one I configure some Python tools to put their caches in /var/cache/ rather than their default locations under $HOME: https://gitlab.com/bkhl/toolboxes/-/blob/master/application/python/Dockerfile

This feels like playing catch-up though. In addition, for most cases I don't use any GUI tools in my projects, so the tight integration with the desktop is not strictly necessary. Most of the time I open tmux inside a Toolbox, and do all my work for a project in there.

I've thought about making a different tool that matches my normal development workflow better, inspired by how some IDE:s with Docker integrations set up development containers:

• (If possible) base the development image on the same image as you'll use to build/deploy the project.
• Layer on your code editing tools, like your text editor, etc.
• Check out a dotfiles Git repository to your home (so that you'll get all your usual configuration files).
• Mount the project directory under $HOME in the container on the same path that it has on your $HOST.

It wouldn't be strictly necessary for me for many projects to replicate the Toolbox integration with the desktop, allowing launching GUI tools etc. I do anticipate that it will be nice sometimes though, so there might be a fair deal of duplication of functionality there, if I do this as a completely different project.

So,

@abitrolly , do you think the above is omething that would interest you?

toolbox-team, is this something you think could fit into the scope of Toolbox, or should I strike out on my own? I understand if you think this doesn't really fit into your goals.

[markstos]

tlbx fork has a -n option to not bind-mount the home directory.

[hholst80]

@abitrolly Why not use podman directly if you really want an isolated environment? Toolbox has a few common use-cases. Try and get those right first before becoming feature complete with the tool it is based on.

[abitrolly]

@hholst80 using podman directly is not convenient.

1. It doesn't store the state if you quit the container, so you can not reentry
2. It doesn't mount current directory by default
3. It doesn't start any image by default

Handling all parameters right for podman is non-trivial, because compared to docker, users also need to be aware to :z :Z flags to volumes, need to understand how share/unshare works. That's why a tool like toolbox is very handy.

[debarshiray]

Duplicate of #183