Toolbox: ホームパスを調整する

私は通常、コンテナを作成する前にHOME=/home/user1/container1を実行し、エイリアスを使用してコンテナを開きます。 （ alias toolbox1='HOME=/home/user1/container1/toolbox "$@"' ）

ええ、 $HOMEをオーバーライドすることはそれを行う1つの方法です。

こんなものも見たいです。 Toolboxの私の主な使用例は、プロジェクトで作業するため、またはソースからソフトウェアをすばやくコンパイルするために、使い捨ての開発環境をセットアップすることです。 何かを一度コンパイルするためだけに、依存関係などからのランダムなファイルでシステムを汚染したくありません。 Toolboxは、ホストをクリーンに保つための分離されたコンテナーを提供すると主張しているため、これには最適のように見えました。

しかし、これは私が期待したとおりには機能しませんでした。 ToolboxはホストOSをクリーンに保ちますが、ホームディレクトリをまったくクリーンに保ちません。 それはまだ完全に汚染されています。 たとえば、使い捨てコンテナを使用してrustを使用するものを作成すると、ホームディレクトリがいくつかの方法で変更されてしまいました。

• ~/.cargoディレクトリがサイレントに作成され、Rust関連のバイナリやソースパッケージなどが合計123MB含まれています。
• ~/.rustupディレクトリがサイレントに作成され、Rust関連のバイナリがさらに多く含まれ、合計683MBになりました。
• 私の~/.bash_profileファイルは、他のすべての前に$ PATHに~/.cargo/binディレクトリを追加するようにサイレントに変更されました。
• 私の~/.profileファイルは、他のすべての前に$ PATHに~/.cargo/binディレクトリを追加するようにサイレントに変更されました。
• 誰が他に何を知っていますか。

うわぁ。 一時的で使い捨ての簡単に廃棄できるシステムであるはずだったものが、私のホームディレクトリに多くの永続的な変更を静かに加えました。 上記のコメントから、$ HOME環境変数を手動でオーバーライドしてこれを回避できることがわかりましたが、これは直感的ではなく、予想もしていませんでした。 Toolboxは（または少なくとも私が理解しているように）コンテナーに入る簡単でユーザーフレンドリーな方法であると想定されているので、これをもっと良い方法で処理できれば幸いです。

私の意見では、ツールボックスにはおそらくデフォルトで独自のユーザーとホームディレクトリが必要です。 しかし、これを実装するには複雑すぎる場合は、新しいツールボックスを作成するときに、デフォルトの$ HOMEを設定するために少なくとも-hまたは--home引数が存在する可能性がありますか？ そのため、将来ツールボックスに入ると、その$ HOME値が自動的に設定されます。 たとえば、 toolbox create -c temp-myproject -h ~/Toolboxes/temp-myprojectに沿ったものです。

基本的に、Toolboxに次の3つのモードのいずれかでコンテナーをセットアップするためのユーザーフレンドリーな方法があれば素晴らしいと思います。

1. シームレスモード：現在の動作。 コンテナユーザーは、実際のホストユーザーであるかのように動作し、ホームディレクトリを共有します。
2. 半分離モード：コンテナはホストユーザーのファイルにアクセスできますが、ソフトウェアがデフォルトで使用するための独自のホームディレクトリがあります。 ホストユーザーのホームディレクトリに読み取り/書き込みを行う場合は、そこに手動でアクセスする必要があります。 基本的には上記のシームレスモードに似ていますが、独自の個別の作業ディレクトリがあります。
3. 完全に分離された（信頼されていない）モード：コンテナーには独自のユーザーとホームディレクトリがあり、ホストユーザーのホームディレクトリにはまったくアクセスできません。 これは、ホームディレクトリ内のすべてを読み取ることを許可したくない信頼できないソフトウェアを実行する場合に役立ちます。

これは私には非常に合理的に聞こえます。 @debarshirayはどう思いますか？

私はこの@JaneSmithをサポートします、私が必要とするすべて-うまく言えば！

私も2番目のアイデアです。 ただし、実装されるまでは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ディレクトリに移動するたびに、それがホームディレクトリであると見なされ、そこから出るとリセットされます。 次のような1つのコマンドでdirenvをインストールした後、すべての手順を実行できます。

`` `bash
mkdir〜 / somedev && echo export HOME = / home / user / somedev>〜/ somedev / .envrc
`` `` ``
私は現在、同様のワークフローを使用しています。

少なくともホームディレクトリをマウントしないオプションがあるはずだということに同意します（https://github.com/containers/toolbox/issues/183#issuecomment-623103780を参照）。 実際には、flatpakと同様に、 ~/.var/app内のいくつかのディレクトリを使用すれば問題ありません。おそらく~/.var/toolbox程度で、ホームディレクトリ内のすべてのファイルがデフォルトで保存されます。
1つのコンテナのすべてのデータが1つの場所にあり、コンテナを削除するとすべてのアプリデータも削除できるため、このフラットパックモデルが非常に気に入っています。 （または、新しい「錆を試した」プロジェクトが取ったスペースを測定するだけです）、たとえば（gnome-control-centerで行われるように）

次に、便宜上、常に現在の$ PWDにマウントする必要があります。プロジェクトフォルダーから開始する場合は、そこにファイルがあることを期待している可能性があります。 ~/rust-projectフォルダには、 ~/Pictures/private/…などへのアクセスは必要ありません。

とにかく、もちろん、オプションで読み取り専用または書き込み可能としてホームにマウントできるはずですが、ほとんどのアプリケーションではそれが本当に必要だとは思いません。
そして、現在の$PWDをマウントできないはずです。

したがって、ここでは新しいデフォルトとして「中間」があります。

tlbx forkには、ホームディレクトリをバインドマウントしないための-nオプションがあります。

https://github.com/containers/toolbox/issues/183の複製

Noooo…別の$ HOMEを使用する他のユースケース/理由がありますが、「開発中のコードのバグやマルウェアを防ぐための分離された開発環境」…

私見、これはまだツールボックスが持つべき機能です。

この問題が解決された理由がわかりません。 それの複製ではありません。 これはセキュリティだけではありません。 私はFedoraSilverblueが大好きで、ペットコンテナをセットアップするためのツールが組み込まれているのが大好きなので、これが再考されることを本当に望んでいますが、現在は実際には機能していません。 そのためだけにフォークを使用する必要はありません...ペットのコンテナ用のツールボックスを使用してさまざまなプログラミングプロジェクトを処理し、ホームディレクトリがコンテナで乱雑にならないようにします。 それはセキュリティとは何の関係もありません。

@JaneSmith必要な機能を備えている場合は、フォークを使用してみませんか？

Toolboxはより多くの開発者でより適切にサポートされており、Fedoraにすぐに含まれているため、フォークではなくToolboxを使用したいと思います。 マシン間を移動するとき、フォークをインストールしなくても、Toolboxはすでに存在しています。 そもそも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で署名する必要があり、サーバーとgit configに接続するためにsshが必要な場合は、次のようなツールボックスを作成できます。

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

それで、これは上流で受け入れられるものですか？ 計画が理にかなっているなら、私もこれに取り組むでしょう。