Toolbox: 调整首页路径

我通常在创建容器之前只做HOME=/home/user1/container1并使用别名来打开它们。 ( alias toolbox1='HOME=/home/user1/container1/toolbox "$@"' )

是的，覆盖$HOME是一种方法。

我也想看到这样的东西。 我对 Toolbox 的主要用例是设置一次性开发环境，用于处理项目，或者只是从源代码快速编译一些软件。 我不想用来自依赖项等的随机文件污染我的系统，只是为了编译一次。 Toolbox 似乎非常适合这一点，因为它声称提供了一个隔离容器来保持主机清洁。

不过，这并没有达到我的预期。 虽然 Toolbox确实保持主机操作系统清洁，但它根本不保持主目录清洁。 那仍然会被完全污染。 例如，使用一次性容器构建使用rust的东西，我的主目录最终以多种方式被更改：

• 一个~/.cargo目录被静默创建，包含许多与 Rust 相关的二进制文件、源包等，总共 123 MB。
• 一个~/.rustup目录被静默创建，包含更多与 Rust 相关的二进制文件，总共 683 MB。
• 我的~/.bash_profile文件被无声地更改为将~/.cargo/bin目录添加到我的 $PATH 中，然后再添加其他所有内容。
• 我的~/.profile文件被无声地更改为将~/.cargo/bin目录添加到我的 $PATH 中，然后再添加其他所有内容。
• 谁知道还有什么。

哎呀。 本来应该是一个临时的、一次性的、易于丢弃的系统，导致我的主目录默默地进行了许多永久性更改。 我现在从上面的评论中意识到，我可以手动覆盖 $HOME 环境变量来尝试解决这个问题，但这对我来说并不直观或不期望。 由于 Toolbox 应该是（或至少据我理解）一种简化且用户友好的进入容器的方式，如果可以以更好的方式处理，我将不胜感激。

我的意见是，默认情况下，工具箱可能应该有自己唯一的用户和主目录。 但是如果这太复杂而无法实现，那么在创建新工具箱时可能至少有一个-h或--home参数来设置它的默认 $HOME？ 这样当您以后进入工具箱时，它会自动设置 $HOME 值。 例如，类似于toolbox create -c temp-myproject -h ~/Toolboxes/temp-myproject的内容。

基本上，我认为如果 Toolbox 有一种用户友好的方式来以三种模式之一设置容器，那就太好了：

1. 无缝模式：现在如何运作。 容器用户就像您的真实主机用户一样，共享您的主目录。
2. 半隔离模式：容器可以访问主机用户的文件，但默认情况下有自己的主目录供软件使用。 如果您想读/写到那里，您需要手动访问主机用户的主目录。 它基本上就像上面的无缝模式，但有自己独立的工作目录。
3. 完全隔离（不受信任）模式：容器将拥有自己独立的用户和主目录，绝对无法访问主机用户的主目录。 这对于运行不受信任的软件很有用，您不想让这些软件读取主目录中的所有内容。

这对我来说听起来很合理。 你觉得@debarshiray 怎么样？

我支持这个@JaneSmith ，我所需要的 - 很好！

我也赞同这个想法。 但在它实施之前，您可以使用direnv 。 它是一个方便的工具，允许您在每个目录的基础上指定环境变量。 您可以使用以下工作流程

- 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

现在每次您进入somedev目录时，它都会假定它是主目录，并在您退出时重置。 在一个命令中安装 direnv 后，您可以执行所有步骤，例如：

``` 重击
mkdir ~/somedev && echo export HOME=/home/user/somedev > ~/somedev/.envrc
````
我目前使用类似的工作流程。

我同意至少应该有一个不挂载主目录的选项（参考 https://github.com/containers/toolbox/issues/183#issuecomment-623103780）。 实际上，如果它使用 - 类似于 flatpak - 在~/.var/app中的某个目录，我什至会很好，也许更好~/.var/toolbox左右，默认情况下保存主目录中的所有文件。
我非常喜欢那个 flatpak 模型，因为你将一个容器中的所有数据放在一个地方，如果你删除容器，你也可以删除所有应用程序数据。 （或者只是测量你的新“我已经尝试过 rust”项目占用的空间），例如（就像在 gnome-control-center 中所做的那样）

然后，为方便起见，它可能总是挂载在当前的 $PWD 中，如果您从项目文件夹启动它，您可能希望其中有文件。 只是，您的~/rust-project文件夹不需要访问~/Pictures/private/…等。

无论如何，当然应该可以选择将 home 挂载为只读甚至可写，但我认为大多数应用程序都不需要这样做。
并且应该能够不安装当前的$PWD 。

所以你会有一个“中间立场”作为新的默认值。

tlbx fork 有一个-n选项来不绑定挂载主目录。

https://github.com/containers/toolbox/issues/183的副本

不……您仍然可以有其他用例/原因来拥有不同的 $HOME 然后是“隔离的开发环境以抵御正在开发的代码中的错误和恶意软件”……

恕我直言，这仍然是工具箱应该具备的功能。

我不明白为什么这个问题被关闭了。 它不是那个的副本。 这不仅仅是安全问题。 我真的希望这会被重新考虑，因为我喜欢 Fedora Silverblue 并且喜欢它有一个内置工具来设置宠物容器，但它目前并没有真正完成这项工作。 我不想为此使用分叉...我使用宠物容器的工具箱来处理各种编程项目，并且我不希望我的主目录被容器弄乱。 它与安全无关。

@JaneSmith如果叉子具有您需要的功能，为什么不使用它？

我更喜欢使用 Toolbox 而不是 fork，因为 Toolbox 得到更多开发人员的更好支持，并且开箱即用地包含在 Fedora 中。 当我从一台机器移动到另一台机器时，工具箱已经在那里，我无需安装叉子。 首先使用 Toolbox 的部分原因是为了避免随机安装软件使我的系统变得混乱！

在我看来，这个功能请求应该是核心的基本功能，因为没有它有点违背 Toolbox 的目的。 我不认为它是一个真正的“外面”不寻常的特殊功能。 因此，我表达了我对它的支持，并希望它将在这个项目中实施。

@JaneSmith我同意所有观点。 我预计该功能将在当前的不安全设计首次公开以参与安全漏洞时实施，如果不是更早的话。

文档中的第一句话说它运行_完全没有特权_。 听起来很安全，对吧？

同样在主要描述中：_这些系统的目的是阻止在主机上安装软件，而是将软件安装为（或在）容器中。_听起来这个项目必须增加重要的安全性。

文档没有在任何地方强调它与每个容器共享您的用户拥有的每个文档，包括与容器中发生的事情无关的 SSH 密钥和文件。

当前的情况不仅不安全，而且会误导人们认为使用这样的容器可以提供显着的安全性，而容器几乎不可能访问您的所有文件！

如果您在 README 中搜索“home”，则没有文档表明您的主目录是以这种方式共享的。

我也想要这个。 中间地带（家庭可访问，但未定义为家庭）和更不受信任的模式（家庭根本无法访问）。

我通常在创建容器之前只做HOME=/home/user1/container1并使用别名来打开它们。 ( alias toolbox1='HOME=/home/user1/container1/toolbox "$@"' )

如果中间解决方案如此简单......那么为什么不能将它作为选项实施到 Toolbox 中呢？ 只需在创建工具箱时将主路径作为参数并将其保存在某处，可能与保存容器名称的方式相同。 然后读取该路径并在进入容器时设置它......

为了让事情更具体一点：

• --new-home将告诉工具箱进入不挂载主机 $HOME（或将其挂载到容器中不是 $HOME 的其他位置）
• --from-home path1:path2:pathN将告诉工具箱输入从主机 $HOME 挂载特定路径到容器主目录

因此，例如，如果我在 ~/Projects 中有源目录，需要使用 gpg 签名并需要 ssh 连接到服务器和我的 git 配置，我可以创建一个像这样的工具箱：

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

那么这是上游接受的东西吗？ 如果计划有意义，我什至会为此努力。