Toolbox: Ajuster le chemin d'accès à la maison

Je fais généralement HOME=/home/user1/container1 avant de créer les conteneurs et j'utilise simplement un alias pour les ouvrir. ( alias toolbox1='HOME=/home/user1/container1/toolbox "$@"' )

Ouais, remplacer $HOME est une façon de le faire.

J'aimerais aussi voir quelque chose comme ça. Mon principal cas d'utilisation de Toolbox consiste à configurer des environnements de développement jetables, soit pour travailler sur des projets, soit simplement pour compiler rapidement des logiciels à partir des sources. Je ne veux pas polluer mon système avec des fichiers aléatoires provenant de dépendances, etc. juste pour compiler quelque chose une fois. Toolbox semblait parfait pour cela, car il prétend fournir un conteneur isolé pour garder l'hôte propre.

Cela ne s'est pas avéré fonctionner tout à fait comme je m'y attendais. Bien que Toolbox garde le système d'exploitation hôte propre, il ne garde pas du tout le répertoire de base propre. Cela devient encore totalement pollué. Par exemple, en utilisant un conteneur jetable pour créer quelque chose qui utilise rust , mon répertoire personnel a fini par être modifié de plusieurs manières :

• Un répertoire ~/.cargo a été créé en silence, contenant de nombreux fichiers binaires liés à Rust, des packages source, etc. pour un total de 123 Mo.
• Un répertoire ~/.rustup a été créé en silence, contenant de nombreux autres binaires liés à Rust, pour un total de 683 Mo.
• Mon fichier ~/.bash_profile a été modifié en silence pour ajouter le répertoire ~/.cargo/bin à mon $PATH avant tout le reste.
• Mon fichier ~/.profile a été modifié en silence pour ajouter le répertoire ~/.cargo/bin à mon $PATH avant tout le reste.
• Qui sait quoi d'autre.

Ouais. Ce qui était censé être un système temporaire, jetable et facile à supprimer a entraîné de nombreuses modifications permanentes apportées silencieusement à mon répertoire personnel. Je réalise maintenant à partir des commentaires ci-dessus que je peux remplacer manuellement la variable d'environnement $HOME pour essayer de contourner cela, mais ce n'était pas intuitif ou prévu pour moi. Étant donné que Toolbox est censé être (ou du moins tel que je le comprends) un moyen simplifié et convivial d'accéder aux conteneurs, j'apprécierais que cela puisse être mieux géré.

Mon opinion est qu'une boîte à outils devrait probablement avoir son propre répertoire utilisateur et personnel unique par défaut. Mais si c'est trop compliqué à implémenter, alors peut-être qu'il pourrait y avoir au moins un argument -h ou --home lors de la création d'une nouvelle boîte à outils, pour définir son $HOME par défaut ? Ainsi, lorsque vous entrerez dans la boîte à outils à l'avenir, cette valeur $HOME sera automatiquement définie. Par exemple, quelque chose comme toolbox create -c temp-myproject -h ~/Toolboxes/temp-myproject .

Fondamentalement, je pense que ce serait formidable si Toolbox disposait d'un moyen convivial de configurer un conteneur dans l'un des trois modes suivants :

1. Mode transparent : Comment ça marche maintenant. L'utilisateur du conteneur agit comme s'il s'agissait de votre véritable utilisateur hôte, partageant votre répertoire personnel.
2. Mode semi-isolé : le conteneur a accès aux fichiers de votre utilisateur hôte, mais possède son propre répertoire d'accueil pour le logiciel à utiliser par défaut. Vous devrez accéder manuellement au répertoire personnel de votre utilisateur hôte si vous souhaitez y lire/écrire. Ce serait essentiellement comme le mode Seamless ci-dessus, mais avec son propre répertoire de travail séparé.
3. Mode entièrement isolé (non approuvé) : le conteneur aurait son propre répertoire d'utilisateur et son propre répertoire d'accueil, sans aucun accès au répertoire d'accueil de votre utilisateur hôte. Cela serait utile pour exécuter des logiciels non fiables, que vous ne voulez pas autoriser à tout lire dans votre répertoire personnel.

Cela me semble très raisonnable. Qu'en pensez-vous @debarshiray ??

Je soutiens ceci @JaneSmith , tout ce dont j'ai besoin - bien dit !

Je seconde l'idée aussi. Mais jusqu'à ce qu'il soit implémenté, vous pouvez utiliser direnv . C'est un outil pratique qui permet de spécifier des variables d'environnement par répertoire. Vous pouvez utiliser le flux de travail suivant

- 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

maintenant, chaque fois que vous allez dans le répertoire somedev , il supposera qu'il s'agit du répertoire personnel et se réinitialise lorsque vous en sortez. Vous pouvez effectuer toutes les étapes après l'installation de direnv en une seule commande, comme :

``` bas
mkdir ~/somedev && echo export HOME=/home/user/somedev > ~/somedev/.envrc
````
J'utilise actuellement un flux de travail similaire.

Je suis d'accord qu'il devrait y avoir au moins une option pour ne pas monter le répertoire personnel (réf https://github.com/containers/toolbox/issues/183#issuecomment-623103780). En fait, je serais même bien s'il utilisait - comme flatpak - un répertoire dans ~/.var/app , peut-être mieux ~/.var/toolbox ou plus, où tous les fichiers du répertoire personnel sont enregistrés par défaut.
J'aime bien ce modèle flatpak, car vous avez toutes les données d'un conteneur au même endroit, et si vous supprimez le conteneur, vous pouvez également supprimer toutes les données de l'application. (ou mesurez simplement l'espace pris par votre nouveau projet "J'ai essayé la rouille"), par exemple (comme cela se fait dans gnome-control-center)

Ensuite, pour plus de commodité, il devrait toujours être monté dans le $PWD actuel, si vous le démarrez à partir d'un dossier de projet, vous vous attendez probablement à y avoir les fichiers. Juste, votre dossier ~/rust-project n'a pas besoin d'accéder à ~/Pictures/private/… etc.

Quoi qu'il en soit, bien sûr, on devrait pouvoir éventuellement monter la maison en lecture seule ou même en écriture, mais je ne pense pas que ce soit vraiment nécessaire pour la plupart des applications.
Et on devrait pouvoir ne pas monter le $PWD actuel.

Vous auriez donc un "terrain d'entente" ici comme nouveau défaut.

tlbx fork a une option -n pour ne pas monter par liaison le répertoire personnel.

Copie de https://github.com/containers/toolbox/issues/183

Noooon… vous pouvez toujours avoir d'autres cas d'utilisation/raisons pour avoir un autre $HOME qu'un "Environnements de développement isolés pour lutter contre les bogues et les logiciels malveillants dans le code en cours de développement"…

À mon humble avis, c'est toujours une fonctionnalité que la boîte à outils devrait avoir.

Je ne comprends pas pourquoi ce sujet a été fermé. Ce n'est pas un doublon de cela. Ce n'est pas seulement une question de sécurité. J'espère vraiment que cela sera reconsidéré car j'aime Fedora Silverblue et j'adore le fait qu'il dispose d'un outil intégré pour configurer des conteneurs pour animaux de compagnie, mais il ne fait pas vraiment le travail actuellement. Je ne veux pas avoir à utiliser un fork juste pour ça... J'utilise toolbox for pet containers pour gérer divers projets de programmation, et je ne veux pas que mon répertoire personnel soit encombré par les conteneurs. Cela n'a rien à voir avec la sécurité.

@JaneSmith pourquoi ne pas utiliser une fourchette si elle possède les fonctionnalités dont vous avez besoin ?

Je préférerais utiliser Toolbox plutôt qu'un fork, car Toolbox est mieux pris en charge avec plus de développeurs et est inclus avec Fedora prêt à l'emploi. Lorsque je passe d'une machine à l'autre, Toolbox est déjà là, sans que j'aie à installer de fourches. Une partie de la raison d'utiliser Toolbox en premier lieu est d'éviter d'encombrer mon système avec des installations de logiciels aléatoires !

À mon humble avis, cette demande de fonctionnalité concerne quelque chose qui devrait être une fonctionnalité de base, car ne pas l'avoir va à l'encontre de l'objectif de Toolbox. Je ne le vois pas comme une fonctionnalité spéciale inhabituelle vraiment "là-bas". Je lui exprime donc mon soutien et espère qu'il sera mis en œuvre pour ce projet.

@JaneSmith Je suis d'accord sur tous les points. Je m'attends à ce que la fonctionnalité soit implémentée la première fois que la conception non sécurisée actuelle est rendue publique pour jouer un rôle dans une faille de sécurité, sinon plus tôt.

La première phrase de la documentation indique qu'il s'exécute _entièrement sans privilège _. Cela semble sûr, hein ?

Également dans la description principale : _L'intention de ces systèmes est de décourager l'installation de logiciels sur l'hôte et d'installer à la place des logiciels en tant que (ou dans) des conteneurs._ Il semble également que ce projet doit ajouter une sécurité importante.

Nulle part les documents ne mettent en évidence qu'il partage tous les documents que votre utilisateur possède avec chaque conteneur, y compris les clés SSH et les fichiers sans rapport avec ce qui se passe dans le conteneur.

La situation actuelle n'est pas seulement précaire, mais induit en erreur l'idée que l'utilisation de conteneurs comme celui-ci offre une sécurité importante, alors que ce n'est guère le cas, les conteneurs peuvent accéder à tous vos fichiers !

Si vous recherchez "home" dans le README, il n'y a aucune documentation indiquant que votre répertoire personnel est partagé de cette manière.

Je veux ça aussi. Un terrain d'entente (accueil accessible, mais pas défini comme ACCUEIL) et un mode plus non fiable (accueil pas accessible du tout).

Je fais généralement HOME=/home/user1/container1 avant de créer les conteneurs et j'utilise simplement un alias pour les ouvrir. ( alias toolbox1='HOME=/home/user1/container1/toolbox "$@"' )

Si une solution intermédiaire est aussi simple... alors pourquoi ne peut-elle pas être implémentée dans Toolbox en option ? Prenez simplement le chemin d'accueil comme argument lors de la création de la boîte à outils et enregistrez-le quelque part, probablement de la même manière que la manière dont le nom du conteneur est enregistré. Ensuite, lisez ce chemin et définissez-le en entrant dans le conteneur...

Pour rendre les choses un peu plus concrètes :

• --new-home qui indiquerait à la boîte à outils de ne pas monter l'hôte $HOME (ou de le monter ailleurs dans le conteneur qui n'est pas $HOME)
• --from-home path1:path2:pathN qui indiquerait à la boîte à outils d'entrer pour monter des chemins spécifiques de l'hôte $HOME à la maison du conteneur

Ainsi, par exemple, si j'ai des répertoires source dans ~/Projects, que j'ai besoin de signer des choses avec gpg et que j'ai besoin de ssh pour me connecter à un serveur et à ma configuration git, je pourrais créer une boîte à outils comme celle-ci :

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

Alors est-ce quelque chose qui serait accepté en amont ? Je travaillerais même là-dessus si le plan avait du sens.