Toolbox: Home-Pfad anpassen

Normalerweise mache ich nur HOME=/home/user1/container1 , bevor ich die Container erstelle, und verwende einfach einen Alias, um sie zu öffnen. ( alias toolbox1='HOME=/home/user1/container1/toolbox "$@"' )

Ja, das Überschreiben $HOME ist eine Möglichkeit, dies zu tun.

So etwas würde ich auch gerne sehen. Mein Hauptanwendungsfall für die Toolbox ist das Einrichten von Wegwerf-Entwicklungsumgebungen, um entweder an Projekten zu arbeiten oder einfach nur schnell Software aus dem Quellcode zu kompilieren. Ich möchte mein System nicht mit zufälligen Dateien aus Abhängigkeiten usw. verschmutzen, nur um einmal etwas zu kompilieren. Toolbox schien dafür perfekt zu sein, da es behauptet, einen isolierten Container bereitzustellen, um den Host sauber zu halten.

Dies funktionierte jedoch nicht ganz so, wie ich es erwartet hatte. Während Toolbox das Host-Betriebssystem sauber hält , hält es das Home-Verzeichnis überhaupt nicht sauber. Das wird immer noch total verschmutzt. Wenn ich beispielsweise einen Wegwerf-Container verwende, um etwas zu bauen, das rust verwendet, wurde mein Home-Verzeichnis auf verschiedene Weise geändert:

• Ein ~/.cargo -Verzeichnis wurde stillschweigend erstellt, das viele Rust-bezogene Binärdateien, Quellpakete usw. mit einer Gesamtgröße von 123 MB enthält.
• Ein ~/.rustup -Verzeichnis wurde stillschweigend erstellt, das viele weitere Rust-bezogene Binärdateien mit einer Gesamtgröße von 683 MB enthält.
• Meine ~/.bash_profile -Datei wurde stillschweigend geändert, um das ~/.cargo/bin -Verzeichnis vor allem anderen zu meinem $PATH hinzuzufügen.
• Meine ~/.profile -Datei wurde stillschweigend geändert, um das ~/.cargo/bin -Verzeichnis vor allem anderen zu meinem $PATH hinzuzufügen.
• Wer weiß was noch.

Huch. Was als temporäres, wegwerfbares, leicht zu verwerfendes System gedacht war, führte dazu, dass viele dauerhafte Änderungen stillschweigend an meinem Home-Verzeichnis vorgenommen wurden. Ich erkenne jetzt aus den obigen Kommentaren, dass ich die $HOME-Umgebungsvariable manuell überschreiben kann, um zu versuchen, dies zu umgehen, aber das war nicht intuitiv oder wurde von mir erwartet. Da Toolbox (oder zumindest so wie ich es verstehe) ein vereinfachter und benutzerfreundlicher Weg sein soll, um in Container zu gelangen, würde ich es begrüßen, wenn dies besser gehandhabt werden könnte.

Meiner Meinung nach sollte eine Toolbox wahrscheinlich standardmäßig einen eigenen eindeutigen Benutzer und ein eigenes Home-Verzeichnis haben. Aber wenn dies zu kompliziert zu implementieren ist, könnte es vielleicht zumindest ein -h - oder --home -Argument geben, wenn Sie eine neue Toolbox erstellen, um ihr Standard-$HOME festzulegen? Wenn Sie also in Zukunft die Toolbox aufrufen, wird dieser $HOME-Wert automatisch gesetzt. Zum Beispiel etwas in der Art von toolbox create -c temp-myproject -h ~/Toolboxes/temp-myproject .

Grundsätzlich fände ich es toll, wenn Toolbox eine benutzerfreundliche Möglichkeit hätte, einen Container in einem von drei Modi einzurichten:

1. Nahtloser Modus: So funktioniert es jetzt. Der Container-Benutzer verhält sich so, als wäre er Ihr echter Host-Benutzer und teilt Ihr Home-Verzeichnis.
2. Halbisolierter Modus: Der Container hat Zugriff auf die Dateien Ihres Host-Benutzers, hat aber standardmäßig ein eigenes Home-Verzeichnis für Software. Sie müssten manuell auf das Home-Verzeichnis Ihres Host-Benutzers zugreifen, wenn Sie dort lesen/schreiben möchten. Es wäre im Grunde wie der nahtlose Modus oben, aber mit einem eigenen separaten Arbeitsverzeichnis.
3. Vollständig isolierter (nicht vertrauenswürdiger) Modus: Der Container hätte sein eigenes separates Benutzer- und Home-Verzeichnis, ohne jeglichen Zugriff auf das Home-Verzeichnis Ihres Host-Benutzers. Dies wäre nützlich, um nicht vertrauenswürdige Software auszuführen, der Sie nicht erlauben möchten, alles in Ihrem Home-Verzeichnis zu lesen.

Das klingt für mich sehr vernünftig. Was denkst du @debarshiray??

Ich unterstütze das @JaneSmith , alles was ich brauche - schön ausgedrückt!

Ich schließe mich der Idee auch an. Aber bis es implementiert ist, könnten Sie direnv verwenden. Es ist ein praktisches Tool, mit dem man Umgebungsvariablen pro Verzeichnis angeben kann. Sie können den folgenden Arbeitsablauf verwenden

- 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

Jetzt wird jedes Mal, wenn Sie in das somedev -Verzeichnis gehen, davon ausgegangen, dass es sich um das Home-Verzeichnis handelt, und zurückgesetzt, wenn Sie es verlassen. Sie könnten alle Schritte nach der Installation von direnv in einem Befehl wie folgt ausführen:

``` bash
mkdir ~/somedev && echo export HOME=/home/user/somedev > ~/somedev/.envrc
````
Ich verwende derzeit einen ähnlichen Arbeitsablauf.

Ich stimme zu, dass es zumindest eine Option geben sollte, das Home-Verzeichnis nicht zu mounten (ref https://github.com/containers/toolbox/issues/183#issuecomment-623103780). Eigentlich wäre es sogar in Ordnung, wenn es – ähnlich wie Flatpak – ein Verzeichnis in ~/.var/app verwendet, vielleicht besser ~/.var/toolbox oder so, wo alle Dateien im Home-Verzeichnis standardmäßig gespeichert werden.
Ich mag dieses Flatpak-Modell sehr, weil Sie alle Daten aus einem Container an einem Ort haben und wenn Sie den Container löschen, können Sie auch alle App-Daten löschen. (oder messen Sie einfach den Platz, den Ihr neues "Ich habe Rost ausprobiert"-Projekt eingenommen hat), z. B. (wie es im Gnome-Kontrollzentrum gemacht wird)

Dann sollte es der Einfachheit halber möglicherweise immer im aktuellen $PWD gemountet werden, wenn Sie es aus einem Projektordner starten, erwarten Sie wahrscheinlich, dass die Dateien dort enthalten sind. Nur Ihr ~/rust-project -Ordner benötigt keinen Zugriff auf ~/Pictures/private/… usw.

Wie auch immer, natürlich sollte man home optional schreibgeschützt oder sogar beschreibbar mounten können, aber ich denke nicht, dass das für die meisten Anwendungen wirklich benötigt wird.
Und man sollte in der Lage sein, das aktuelle $PWD nicht zu mounten.

Sie hätten hier also einen "Mittelweg" als neue Vorgabe.

Der tlbx- Fork hat eine -n -Option, um das Home-Verzeichnis nicht per Bind-Mount einzuhängen.

Duplikat von https://github.com/containers/toolbox/issues/183

Neeeeeeeeeeeeeein… es kann immer noch andere Anwendungsfälle/Gründe für ein anderes $HOME geben als „Isolierte Entwicklungsumgebungen zur Abwehr von Bugs und Malware in Code in der Entwicklung“…

IMHO ist dies immer noch eine Funktion, die Toolbox haben sollte.

Ich verstehe nicht, warum dieses Thema geschlossen wurde. Es ist kein Duplikat davon. Hier geht es nicht nur um Sicherheit. Ich hoffe wirklich, dass dies noch einmal überdacht wird, da ich Fedora Silverblue liebe und es liebe, dass es ein eingebautes Tool zum Einrichten von Haustiercontainern hat, aber es erfüllt derzeit nicht wirklich die Aufgabe. Ich möchte nicht nur dafür einen Fork verwenden müssen ... Ich verwende die Toolbox für Pet-Container, um mit verschiedenen Programmierprojekten fertig zu werden, und ich möchte nicht, dass mein Home-Verzeichnis von den Containern überladen wird. Mit Sicherheit hat das nichts zu tun.

@JaneSmith warum nicht einen Fork verwenden, wenn er die Funktionen hat, die Sie benötigen?

Ich würde lieber Toolbox als einen Fork verwenden, da Toolbox von mehr Entwicklern besser unterstützt wird und standardmäßig in Fedora enthalten ist. Wenn ich mich von Maschine zu Maschine bewege, ist die Toolbox bereits da, ohne dass ich Gabeln installieren muss. Einer der Gründe für die Verwendung von Toolbox besteht in erster Linie darin, mein System nicht mit willkürlichen Softwareinstallationen zu überladen!

Meiner bescheidenen Meinung nach handelt es sich bei dieser Feature-Anfrage um etwas, das Kern-, Grundfunktionalität sein sollte, da es den Zweck von Toolbox irgendwie zunichte macht, wenn man es nicht hat. Ich sehe es nicht als eine wirklich "draußen" ungewöhnliche Besonderheit. Deshalb befürworte ich es und hoffe, dass es für dieses Projekt umgesetzt wird.

@JaneSmith Ich stimme in allen Punkten zu. Ich gehe davon aus, dass die Funktion implementiert wird, wenn das aktuelle unsichere Design zum ersten Mal veröffentlicht wird, um eine Rolle bei einer Sicherheitsverletzung zu spielen, wenn nicht früher.

Der erste Satz in der Dokumentation besagt, dass es _vollständig unprivilegiert _ ausgeführt wird. Klingt sicher, oder?

Auch in der Hauptbeschreibung: _Die Absicht dieser Systeme ist es, die Installation von Software auf dem Host zu verhindern und stattdessen Software als (oder in) Containern zu installieren._ Es klingt auch so, als ob dieses Projekt erhebliche Sicherheit bieten muss.

Nirgendwo wird in den Dokumenten hervorgehoben, dass jedes Dokument, das Ihr Benutzer besitzt, mit jedem Container geteilt wird, einschließlich SSH-Schlüsseln und Dateien, die nichts mit dem zu tun haben, was im Container passiert.

Die aktuelle Situation ist nicht nur unsicher, sondern verleitet auch dazu, zu vermitteln, dass die Verwendung solcher Container erhebliche Sicherheit bietet, obwohl die Container kaum auf alle Ihre Dateien zugreifen können!

Wenn Sie in der README nach „home“ suchen, gibt es keine Dokumentation, dass Ihr Home-Verzeichnis auf diese Weise freigegeben wird.

Ich will das auch. Ein Mittelweg (Zuhause zugänglich, aber nicht als ZUHAUSE definiert) und ein nicht vertrauenswürdiger Modus (Zuhause überhaupt nicht zugänglich).

Normalerweise mache ich nur HOME=/home/user1/container1 , bevor ich die Container erstelle, und verwende einfach einen Alias, um sie zu öffnen. ( alias toolbox1='HOME=/home/user1/container1/toolbox "$@"' )

Wenn eine Mittelweglösung so einfach ist... warum kann sie dann nicht als Option in Toolbox implementiert werden? Nehmen Sie beim Erstellen der Toolbox einfach den Home-Pfad als Argument und speichern Sie ihn irgendwo, wahrscheinlich auf die gleiche Weise wie der Containername gespeichert wird. Lesen Sie dann diesen Pfad und setzen Sie ihn beim Betreten des Containers ...

Um es etwas konkreter zu machen:

• --new-home was der Toolbox-Eingabe mitteilen würde, den Host $HOME nicht zu mounten (oder ihn an einer anderen Stelle im Container zu mounten, die nicht $HOME ist)
• --from-home path1:path2:pathN was der Toolbox-Eingabe mitteilen würde, bestimmte Pfade vom Host $HOME zum Container-Home zu mounten

Wenn ich zum Beispiel Quellverzeichnisse in ~/Projects habe, Dinge mit gpg signieren muss und ssh brauche, um eine Verbindung zu einem Server und meiner Git-Konfiguration herzustellen, könnte ich eine Toolbox wie diese erstellen:

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

Ist das also etwas, das stromaufwärts akzeptiert würde? Ich würde sogar daran arbeiten, wenn der Plan Sinn macht.