Journal Comment faire une sandbox de mon système de fichier ?

Posté par (page perso) . Licence CC by-sa
9
6
jan.
2015

J'ai un petit problème, et j'aimerais votre avis sur comment le résoudre. Je vous propose également une solution que j'ai réalisée (mais avec certaines limitations). Mon cas d'utilisation est simple. Je viens de cloner un projet depuis son dépôt Git, je l'ai compilé, et j'aimerais éviter de faire un make install bien crade.

Pourquoi c'est crade ? Déjà parce que tous les projets ne fournissent pas toujours un make uninstall, et qu'ensuite, il n'y a aucune façon de bien vérifier que le make uninstall enlève bien tout. Donc je ne le fais simplement pas.

Ce que je fais, c'est un make DESTDIR=$PWD/root install qui va tout m'installer dans root/usr/local/.... Et j'aimerais exécuter ces fichiers. Sauf que comme l'application n'est pas relocalisable, ce n'est pas possible.

J'ai pensé qu'il serait possible avec OverlayFS + chroot d'arriver a mes fins. OverlayFS se chargerait de monter quelque part une image de mon système de fichier complet (/) ne lecture seule, et d'y inscrire un dossier $PWD/root en lecture-ecriture. Il ne reste plus qu'un chroot pour entrer dans de dossier, et le tour est joué.

C'est le rôle du projet ovroot (pour overlay chroot) qu'il est possible de trouver sur github. Mon principal problème est que OverlayFS va monter une image de ma partition racilee (/), mais pas de mes fichiers personnels (/home) ni de plein de trucs super utiles comme /run, /proc, /dev ou /sys. Cela semble être une limitation de ce que peut faire OverlayFS.

Et vous, connaissez-vous un projet qui puisse faire quelque chose de similaire ?

  • # Checkinstall sur debian-like

    Posté par . Évalué à 10.

    Si tu es sur debian ou assimilé, je te conseille l'excellent checkinstall qui va surveiller le make install et créer un paquet .deb contenant le logiciel installé. Ainsi tu pourra désinstaller le soft avec apt.

    Sur les systèmes type archlinux ou gentoo les recettes de création de paquets (PKGBUILDs, ebuilds) sont tellement simple à écrire (si on tiens pas à faire propre, mais ici la recette reste chez toi) que la meilleure solution est sans doute de t'en faire une pour ton soft, la recette n'étant qu'un peu de boilerplate autour du configure - make - make install.

    Sous distro rpm, j'en sais rien désolé :/.

    • [^] # Re: Checkinstall sur debian-like

      Posté par . Évalué à 7.

      Sous distro rpm, j'en sais rien désolé :/.
      checkinstall fonctionnait bien sous feu Mandrake 10.1, pas de raison que ça ait changé depuis.
      Au pire un checkinstall qui crée un deb, puis un alien pour le transformer en .rpm. Ça ne gère de toutes façons pas les dépendances correctement, mais ça évitera les résidus d'installation.

  • # Conteneur léger tel que Docker

    Posté par . Évalué à 5. Dernière modification le 06/01/15 à 17:04.

    Docker peut répondre à ta problématique.

    • [^] # Re: Conteneur léger tel que Docker

      Posté par . Évalué à 4.

      C'est pour vendre ta solution que tu met "Conteneur léger" dans le titre?
      Car, si je ne m'abuse, un conteneur, c'est peut-être léger quand on le compare à une VM (et on peut aisément le faire car le cas d'utilisation est de répondre aux même problématiques), mais c'est absolument pas léger dans l'absolu!
      Ton conteneur contient toutes les dépendances sous-jacentes (excepté le noyau), donc il y a un grande chance que ton conteneur fasse dans les 100Mo (ordre de grandeur si il est pas fait aux petite oignons.)
      Et surtout en mémoire, il prendra un peu de place, au mieux si tu as la même version des binaires dans en dehors du conteneur (et que le noyau fait de la dé-duplication de pages mémoire) et au pire, ben toutes les libs sont différentes et tu montes tout en mémoire.

      Tout ça pour dire, qu'il vaut mieux ne pas utiliser "conteneur" avec "léger" ;) (sauf si tu compares avec les VMs)

      • [^] # Re: Conteneur léger tel que Docker

        Posté par . Évalué à 6. Dernière modification le 06/01/15 à 21:16.

        Premier point, je n'ai rien à vendre. C'est juste une technologie qui je connais et avec lequel je m'amuse pas mal, point.

        Mais 100Mo c'est vraiment si lourd ?

        Y a des conteneur qui font bien moins que 100Mo tout dépend ce que tu veut faire.
        Si tu fais un tar cv --files-from /dev/null | docker import - scratch
        tu te retrouve avec un conteneur qui a un overhead null. Pour des programmes compilés statiquement (trivial a faire pour des programmes écrit en go si tu utilise le compilateur cgo par exemple) tu as juste ton programme et rien de plus. Pas mal non ?
        Si tu veux avoir des librairies dynamique rien ne t’empêche de les avoir sur ton OS ou dans un autre conteneur et de faire des mount-bind (docker volume).
        Tu as aussi des images busybox qui font ~50Mo et l'image debian de base fait 83Mo.
        Sachant qu'en plus avec docker tu utilise généralement soit aufs (unionfs) ou btrfs(copy on write) comme système de fichier tu peux pas vraiment dire qu'il y a un overhead, t'as 10 images basé sur la debian base tu te retrouve qu'avec un seul fois les 83Mo (copy on write ou unionfs).

        Donc si c'est léger en taille. (Après en ressource kernel avec tout les namespaces crée c'est une autre histoire).

        Et puis l'idée du titre c'était de parler de conteneur léger. Y a pas que docker, y a lmctfy de chez google , rocket de chez coreos, lxc etc… Le principe de l'isolation n'a pas été inventé chez docker.

        • [^] # Re: Conteneur léger tel que Docker

          Posté par . Évalué à 4.

          Mais 100Mo c'est vraiment si lourd ?

          Ça dépend si on fait un retour vers le passé (on est la bonne année), en 1989 un gros disque dur faisait 100Mo et les monstres de guerre avaient 8Mo de RAM.
          En 2015 c'est les systèmes embarqués qui sont parfois limités en mémoire vive et ou mémoire morte.
          Donc oui c'est lourd dans certains cas.
          Bon soyons honnête même pour un PC bas de gamme de notre époque qui n'a "que" 4Go de RAM et 1To de Dur, cent meg c'est pas grand chose.

          kentoc'h mervel eget bezan saotred

    • [^] # Re: Conteneur léger tel que Docker

      Posté par (page perso) . Évalué à 3.

      LA solution pour répondre au besoin exposé…

      Docker est excellent pour le dev et le test, c'est une evidence.

  • # Commentaire supprimé

    Posté par (page perso) . Évalué à 2. Dernière modification le 06/01/15 à 17:48.

    Ce commentaire a été supprimé par l'équipe de modération.

    • [^] # Mon commentaire sur les commentaires supprimés sans commentaires du modérateur

      Posté par . Évalué à 10.

      Je suis toujours dubitatif avec les messages supprimé comme ça.

      J'ai aucune idée de ce qui a pu entrainer une suppression en commentaire racine par un membre de linuxfr depuis plus de 5 ans (il n'a probablement pas insulté, ni fait de la publicité par exemple).

      Ça me démange toujours de savoir ce qu'il y avait avant :)

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Mon commentaire sur les commentaires supprimés sans commentaires du modérateur

        Posté par (page perso) . Évalué à 3.

        Doublon supprimé à la demande de l'auteur

        • [^] # Re: Mon commentaire sur les commentaires supprimés sans commentaires du modérateur

          Posté par (page perso) . Évalué à 7. Dernière modification le 06/01/15 à 19:01.

          Roh même pas un complot à se mettre sous la dent?

          Ceci étant, ce compte n'a rien posté dans ce journal, alors quel doublon est possible?

          ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

          • [^] # Re: Mon commentaire sur les commentaires supprimés sans commentaires du modérateur

            Posté par . Évalué à 10.

            La Cabale n'existe pas.

          • [^] # Re: Mon commentaire sur les commentaires supprimés sans commentaires du modérateur

            Posté par . Évalué à 4. Dernière modification le 07/01/15 à 09:28.

            Si je me souviens bien, il avait écrit un truc du genre "Docker c'est super adapté pour ton cas, edit grilled, merci à la modération de supprimer ce commentaire" (cf. le commentaire d'avant qui en avait parlé avant, du coup celui-ci faisait doublon). Bref, ça aurait été mieux de supprimer tout le commentaire, ou de le laisser dans son intégralité, si c'était pour éviter la pollution visuelle.

            • [^] # Re: Mon commentaire sur les commentaires supprimés sans commentaires du modérateur

              Posté par (page perso) . Évalué à 10.

              • Tu laisses le commentaire et s'en suivra un fil de discussion sur les doublons, le non-respect de la demande de l'auteur, les licences et l'orthographe.
              • Tu enlèves complètement le commentaire et quelqu'un va râler sur la censure, s'en suivra une longue discussion sur la différence entre la censure et la modération, les règles de modération et l'orthographe. Ensuite viendra un débat sur le fait que ces commentaires sur la forme plutôt que le fond c'est pénible, et que franchement ça serait mieux de parler du sujet du contenu. Là on objectera que l'important c'est le voyage, pas la destination. Mais quand même c'est important de débattre sur l'éthique, la possibilité de débattre et la non-existence de la Cabale.
              • Tu masques le commentaire et quelqu'un va râler sur la pollution visuelle du commentaire masqué, l'absence de raison, les autres possibilités qui étaient la suppression complète ou la non-modification et l'orthographe. Mais n'aurait-on pas dû aborder le sujet du contenu ? Néanmoins la transparence, la rhétorique et l'importance de l'exactitude sur Internet peuvent-ils souffrir de l'absence de l'information cruciale sur ce commentaire-là ?
              • Tu remplaces ce commentaire par un conteneur Docker, léger ou pas faut voir, pour débattre de qui est le plus fort entre l'éléphant et l'hippopotame.
              • Merci aux modérateurs de supprimer mon commentaire.
              • [^] # Re: Mon commentaire sur les commentaires supprimés sans commentaires du modérateur

                Posté par . Évalué à 5.

                En fait, je crois qu'il faut juste indiquer la raison lors de la suppression, comme tu as été obligé de le faire pour apporter la justification. Genre:

                Ce commentaire a été supprimé par l'équipe de modération: demande de l'auteur.

                ou

                Ce commentaire a été supprimé par l'équipe de modération: censure.

                Car il est vrai qu'on peut être un peu suspicieux lorsqu'on voit un tel message (mais ça n’empêchera pas ceux qui croient à la théorie du complot de crier ;) )

              • [^] # Re: Mon commentaire sur les commentaires supprimés sans commentaires du modérateur

                Posté par . Évalué à 3.

                Tu enlèves complètement le commentaire et quelqu'un va râler sur la censure,

                oui, sauf que quand le commentaire est tendancieux (genre "une distribution se crashe sur un banc de moule après avoir hurlé 'systemd aquebar'") ceux qui se souviennent vont peut-être crier à la censure, alors que si c'est un doublon supprimé à la demande du posteur initial, ceux qui s'en souviendront sauront que c'était anodin et bien loin des malversation de la cabale (qui n'existe pas).

              • [^] # Re: Mon commentaire sur les commentaires supprimés sans commentaires du modérateur

                Posté par . Évalué à 7.

                Mon message manquait probablement de smiley. Je ne cherchais pas le moins du monde à créer un polémique (si si je vous jure) et je ne remet pas du tout en question la pertinence de la modération (qui est très légère sur dlfp).

                Je suis juste très curieux rien de plus :)

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # sandbox

    Posté par (page perso) . Évalué à 5.

    La distribution gentoo utilise un logiciel nommé sandbox pour cela. Cela créé un bac à sable à partir d'un répertoire. Les accès à ce répertoire et à ses enfants sont autorisés. Les accès aux autres répertoires peuvent être autorisé ou interdit en lecture et/ou en écriture.

    Cela te permettrait de tester les install/uninstall et voir s'il n'y a pas de fichiers qui trainent après une désinstallation (et si le DESTDIR est bien respecté au passage !).

    Un point à noter : cela ne créé pas d'environnement chrooté.

    Par contre, cela ne résout pas le soucis de l'exécution…

  • # proot

    Posté par . Évalué à 10.

    Non, ce n'est pas un bruit gastrique suite aux bacchanales récentes. Proot est un outil regroupant les fonctionnalités d'un chroot et d'un mount --bind.

    Exactement ce que tu veux donc. Joyeux noël, en avance de 359 jours. Remarque, on n'a jamais été aussi près de Noël en 2015.

  • # --prefix ?

    Posté par (page perso) . Évalué à 10.

    Salut,

    Corrige moi si je me trompe, mais ta problématique est simplement d'installer un programme auto-compilé, que tu comptes vraiment utiliser (et pas juste tester)?
    Parce que le sandbox, c'est plus pour des tests, par exemple pour sécuriser tes données si tu n'as pas entièrement confiance au programme exécuté, ou si c'est une version de dév un peu instable, ou que sais-je encore. Mais si ta problématique est uniquement que tu veux pas faire d'install crade, ça me paraît disproportionné.

    Si ton programme utilise les autotools, il suffit de mettre l'option --prefix au script configure:

    ./configure --prefix=$HOME/.local --autre --options
    make && make install

    Les autres systèmes de compilation ont (tous ceux qui se respecte, à ma connaissance) aussi un moyen de spécifier le préfixe d'installation, par exemple lors de la phase cmake, etc.

    $HOME/.local est un préfixe assez classique pour installer des logiciels pour ton user seulement (mais ça mélangera les divers logiciels si tu en installes d'autres avec ce même préfixe). Tu n'as même pas besoin d'être root pour le make install (en fait, de manière général, je déconseille d'installer quoi que ce soit d'auto-compilé en root, sauf si vous êtes vraiment sûr de vous).
    Sinon souvent on va installer dans /opt/nom-du-logiciel/ ou quoi que tu veuilles. Il suffit juste de bien mettre à jour la variable d'environnement $PATH.
    Par exemple dans ton ~/.bashrc:

    export PATH="$HOME/.local/bin:$PATH"

    Ensuite quand tu veux désinstaller, si tu as utilisé un préfixe unique avec aucun autre logiciel installé dedans, tu peux juste effacer tout le répertoire.

    Note que DESTDIR fait quelque chose de similaire, sauf que ce n'est absolument pas fait pour une installation finale. C'est plutôt fait pour créer votre arborescence, préfixe compris, dans un répertoire pour ensuite le déplacer ailleurs, cette fois au bon préfixe. L'utilisation la plus commune est la création de paquet, pour une utilisation sur plusieurs machines, par exemple dans un parc informatique, ou bien pour une distribution Linux, etc.
    En gros on donne à --prefix l'emplacement qui sera utilisé au final par le logiciel dans la machine cible, alors que DESTDIR n'est qu'un emplacement temporaire, en préparation du paquet, sur la machine de compilation et ne doit avoir absolument aucun impact sur l'installation finale.

    En fait c'est même sujet à bug d'utiliser DESTDIR pour une installation finale. En effet, le logiciel peut potentiellement utiliser le préfixe déterminé à la configuration (qui peut alors être inclus dans les sources avant compilation); par exemple pour connaître l'emplacement de données (permettant ainsi les binaires et les données d'être dans un préfixe différent notamment).
    DESTDIR par contre ne sert à rien et ne sera jamais utilisé par le logiciel final. Tu risques donc de "casser" le logiciel si ton installation repose sur l'usage de DESTDIR.

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: --prefix ?

      Posté par . Évalué à 2.

      Je pense aussi que la solution que l'auteur cherche est --prefix, la seul option vraiment utilisé à l'usage des ./configure.

      "La première sécurité est la liberté"

    • [^] # Re: --prefix ?

      Posté par . Évalué à 2.

      Cela a aussi a quelques inconvénients, au minium
      - le bricolage du path,
      - mais aussi le ld.so.conf puis ldconfig et/ou l'équivalent en variable d'environnement (?),
      - et enfin, la séparation totale du système, donc les fichiers pour etc, var, run, arrivent dans des endroits bizarres dont il faut tenir compte, par exemple pour logrotate si besoin.

      Je dis pas que c'est mal, hein. Juste que c'est rapidement très chiant.

      • [^] # Re: --prefix ?

        Posté par (page perso) . Évalué à 3.

        Salut,

        Tu as raison, mais en même temps, c'est ce que l'auteur veut: une séparation de certains logiciels du reste du système. Et je suis pas sûr que ce soit beaucoup plus chiant que les alternatives proposées (sandboxing!).
        Et si on utilise toujours le même préfixe alternatif, alors on n'a pas à mettre a jour les variables d'environnement 100 fois, juste la première fois. En fait tout dépend vraiment du type d'utilisation que l'auteur du journal avait en vue, ce qui n'est pas très clair pour moi. Si c'est juste pour utiliser un logiciel stable régulièrement et que la seule chose qu'elle souhaitait éviter était de mélanger des données et binaires installés manuellement avec le système principal (ce qui serait en effet une très mauvaise idée), alors un --prefix est je pense le plus simple.

        Ensuite comme quelqu'un propose plus bas, y a aussi la solution de faire un paquet pour le système cible, ce qui permet à la fois d'installer avec le reste du système (et donc de n'avoir aucune variable à mettre à jour) tout en ayant une (dés)installation propre.
        Par contre ça implique de savoir rapidement faire un paquet (là encore ça va, c'est comme tout, ça s'apprend; mais ça reste tout de même un point de complexité supplémentaire par rapport à un simple --prefix), mais surtout ça rend les modifications plus dur, ce qui est embêtant si le but était aussi de pouvoir modifier le programme (ce qui est souvent la raison pour laquelle je compile moi-même certains logiciels).
        Bien sûr, si ce n'est pas le cas de Mildred et qu'elle n'a aucune intention de modifier le logiciel, alors c'est aussi une alternative intéressante.

        Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

  • # Ma solution

    Posté par . Évalué à 2.

    Pour ce problème, je me crée à la va-vite un paquet rpm. Je peux tester l'installation et la désinstallation (et le programme) avec un chroot créé par mock (qui fait aussi la compilation du paquet).

    C'est juste ma solution.

    Si j'ai pas rpm, "./configure --prefix=…." comme le mentionne quelqu'un d'autre.

    • [^] # Re: Ma solution

      Posté par . Évalué à 1.

      Bonjour,
      mon experience personnelle m'a appris qu'il est bien de spécifié aussi l'option exec_prefix

      "./configure --prefix= --exec-prefix="

      Souvent le premier suffit mais parfois il faut les 2 .

  • # Stow

    Posté par (page perso) . Évalué à 5.

    Si tu n'as pas besoin d'isoler ton programme des autres, tu peux utiliser stow. Il permet d'installer un programme dans un répertoire et de créer des liens dans /usr/local pour qu'il fonctionne correctement.
    Sinon des fois, j'utilise un truc maison.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.