Toolbox: Adjust home path

I usually just do HOME=/home/user1/container1 before creating the containers and just use an alias to open them. (alias toolbox1='HOME=/home/user1/container1/toolbox "$@"')

Yeah, overriding $HOME is one way to do it.

I'd also like to see something like this. My main use case for Toolbox is to set up throwaway development environments, for either working on projects, or just quickly compiling some software from source. I don't want to pollute my system with random files from dependencies, etc. just to compile something once. Toolbox seemed perfect for this, as it claims to provide an isolated container to keep the host clean.

This didn't turn out to work quite how I expected though. While Toolbox does keep the host OS clean, it doesn't keep the home directory clean at all. That still gets totally polluted. For example, using a throwaway container to build something that uses rust, my home directory ended up getting altered in several ways:

• A ~/.cargo directory was silently created, containing many Rust-related binaries, source packages, etc. for a total of 123 MB.
• A ~/.rustup directory was silently created, containing many more Rust-related binaries, for a total of 683 MB.
• My ~/.bash_profile file was silently altered to add the ~/.cargo/bin directory to my $PATH ahead of everything else.
• My ~/.profile file was silently altered to add the ~/.cargo/bin directory to my $PATH ahead of everything else.
• Who knows what else.

Yikes. What was supposed to be a temporary, throwaway, easy-to-discard system resulted in many permanent changes being silently made to my home directory. I realise now from the comments above that I can override the $HOME environment variable manually to try to work around this, but this was not intuitive or expected to me. Since Toolbox is supposed to be (or at least as I understand it) a simplified and user-friendly way to get into containers, I would appreciate if this could be handled in some better way.

My opinion is that a Toolbox should probably have its own unique user and home directory by default. But if this is too complicated to implement, then perhaps there could at least be a -h or --home argument when creating a new toolbox, to set its default $HOME? So that when you enter the toolbox in future, it would get that $HOME value set automatically. For example, something along the lines of toolbox create -c temp-myproject -h ~/Toolboxes/temp-myproject.

Basically, I think it would be great if Toolbox had a user-friendly way to set up a container in one of three modes:

1. Seamless mode: How it works now. The container user acts as if it's your real host user, sharing your home directory.
2. Semi-isolated mode: The container has access to your host user's files, but has its own home directory for software to use by default. You would need to manually access your host user's home directory if you want to read/write to there. It would basically be like the Seamless mode above, but with its own separate working directory.
3. Fully-isolated (untrusted) mode: The container would have its own separate user and home directory, with absolutely no access to your host user's home directory. This would be useful for running untrusted software, which you don't want to allow to read everything in your home directory.

This sounds very reasonable to me. What do you think @debarshiray??

I support this @JaneSmith , all I need - nicely put!

I second the idea too. But until it gets implemented you could use direnv. It is a handy tool that allows one to specify environment variables on a per directory basis. You can use the following work flow

- install direnv and hook it to your shell
- create a temporary directory eg. ~/somedev
- add a .envrc file with the environment variables you want (in this case HOME=/home/user/somedev

now every time you go into the somedev directory it will assume it is the home directory and resets when you step out of it . You could do all the steps after installing direnv in one command like:

``` bash
mkdir ~/somedev && echo export HOME=/home/user/somedev > ~/somedev/.envrc
````
I currently use a similar work flow.

I agree there should at least be an option to not mount the home dir (ref https://github.com/containers/toolbox/issues/183#issuecomment-623103780). Actually, I would even be fine if it uses – similar to flatpak – some dir in ~/.var/app, maybe better ~/.var/toolbox or so, where all files in the home dir are saved by default.
I quite like that flatpak model, because you have all the data from one container in one place, and if you delete the container, you can also delete all app data. (or just measure the space your new "I've tried out rust" project took), e.g. (as it's done in gnome-control-center)

Then, for convenience, it should possibly always mount in the current $PWD, if you start it from a project folder, you likely expect to have the files in there. Just, your ~/rust-project folder, does not need any access to ~/Pictures/private/… etc.

Anyway, of course one should be able to optionally mount home as read-only or even writable, but I don't think that is really needed for most applications.
And one should be able to not mount the current $PWD.

So you'd have a "middle-ground" here as a new default.

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

Duplicate of https://github.com/containers/toolbox/issues/183

Noooo… you can still have other use cases/reasons for having a different $HOME then an "Isolated development environments to fend against bugs and malware in code under development"…

IMHO, this is still a feature that toolbox should have.

I don't understand why this issue was closed. It's not a duplicate of that. This isn't just about security. I really hope this will be reconsidered as I love Fedora Silverblue and love that it has a built-in tool to set up pet containers, but it doesn't really do the job currently. I don't want to have to use a fork just for that... I use toolbox for pet containers to deal with various programming projects, and I don't want my home directory to be cluttered by the containers. It has nothing to do with security.

@JaneSmith why not use a fork if it has the features you need?

I'd prefer to use Toolbox rather than a fork, because Toolbox is better supported with more developers, and is included with Fedora out of the box. When I'm moving from machine to machine, Toolbox is already there, without me having to install forks. Part of the reason for using Toolbox in the first place is to avoid cluttering my system with random software installations!

In my humble opinion, this feature request is for something that should be core, basic functionality, as not having it kind of defeats the purpose of Toolbox. I don't see it as a really "out there" unusual special feature. I'm therefore voicing my support for it and hoping that it will be implemented for this project.

@JaneSmith I agree on all points. I expect the feature will be implemented the first time the current insecure design is publicized to play a part in a security breach, if not sooner.

The first sentence in the docs says it runs _fully unprivileged _. Sounds secure, huh?

Also in the main description: _The intention of these systems is to discourage installation of software on the host, and instead install software as (or in) containers._ Also sounds like this project must add significant security.

Nowhere do the docs highlight that it's sharing every document your user owns with with every container, including SSH keys and files unrelated to what's happening in the container.

The current situation is not only insecure, but misleads to convey that using containers like this provides significant security, when it's hardly the case the containers can access all your files!

If you search for "home" in the README, there is no documentation that your home directory is shared in this way.

I want this too. A middle ground (home accessible, but not defined as HOME), and a more untrusted mode (home not accessible at all).

I usually just do HOME=/home/user1/container1 before creating the containers and just use an alias to open them. (alias toolbox1='HOME=/home/user1/container1/toolbox "$@"')

If a middle ground solution is this simple... then why can't it be implemented into Toolbox as an option? Just take the home path as an argument when creating the toolbox and save it somewhere, probably the same way as how the container name is saved. Then read that path and set it when entering the container...

To make things a bit more concrete:

• --new-home which would tell toolbox enter to not mount host $HOME (or mount it somewhere else in the container which is not $HOME)
• --from-home path1:path2:pathN which would tell toolbox enter to mount specific paths from host $HOME to the container home

So for example if I have source directories in ~/Projects, need to sign things with gpg and need ssh to connect to a server and my git config I could create a toolbox like this:

toolbox create --new-home --from-home Projects:.ssh:.gnupg:.gitconfig

So is this something would be accepted upstream? I would even work on this if the plan makes sense.