CDE : un outil pour le déploiement de binaires sans installation de dépendances

Posté par  . Modéré par baud123.
Étiquettes :
14
14
nov.
2010
Linux
CDE est un logiciel libre (licence GNU GPL v3) basé sur strace et développé par Philip J. Guo, étudiant en thèse de doctorat à l'université de Stanford, qui permet d'encapsuler toutes les dépendances d'un binaire et de créer un bac à sable afin que ce binaire soit exécutable sur toute autre machine Linux sans autre installation.

CDE encapsule tous les fichiers nécessaires à l'exécution du binaire : Code, Données, Environnement. Ainsi, lors de l'exécution de la commande $ cde a.out sur la machine A, CDE va exécuter a.out, surveiller ses accès (bibliothèques dynamiques, fichiers de configuration, polices, etc.), copier ces fichiers dans un sous-répertoire et créer un fichier a.out.cde. L'ensemble des fichiers de ce sous-répertoire peut être transféré sur une machine B. Lors de l'exécution de a.out.cde, l'environnement est changé (comme avec chroot) et ce sont les bibliothèques fournies dans le sous-répertoire qui sont utilisées. Le binaire ainsi encapsulé est exécutable sur une autre machine à deux conditions : premièrement, que les deux machines soient de la même architecture (par exemple x86) ; deuxièmement, qu'elles utilisent la même version majeure du noyau (par exemple 2.6).

Parmi les utilisations possibles (de nombreux autres exemples sont donnés sur la page du projet) :
  • Laisser en téléchargement des binaires qui s'exécuteront chez tous les utilisateurs sans qu'ils aient à installer des dépendances, à compiler, ou à installer une machine virtuelle ;
  • Permettre l'exécution de programmes binaires anciens sur des machines récentes, ou le contraire ;
  • Soumettre un rapport de bug exécutable permettant sa reproduction chez les développeurs.

Aller plus loin

  • # Avantage par rapport à un simple ldd ?

    Posté par  . Évalué à -10.

    moi je ferais un simple ldd pour voir les lib requises...

    pour les fichiers en relation... dans les commentaires de la vidéo, il semble qu'il inclue /etc/passwd...

    J'trouve vraiment pas ça utile... et evidemment ca ne marche pas si on produit sur du x86_64 et le fait tourner sur du x86 32 bits.

    Donc pour moi ça a aucun intéret.

    Faut être en doctorat pour faire ce genre de truc inutile ?

    • [^] # Re: Avantage par rapport à un simple ldd ?

      Posté par  . Évalué à 7.

      >>moi je ferais un simple ldd pour voir les lib requises...
      Je ne pense pas qu'avec ldd tu puisses connaitre les lib chargées par le programme dynamiquement (dlopen) comme pour les plugins.

      Pour strace il faut être certain d'avoir chargé tous les composants...

      • [^] # Re: Avantage par rapport à un simple ldd ?

        Posté par  . Évalué à 1.

        En effet, pour dlopen j'y ai pensé après. Mais soit le binaire tu l'as codé et tu sais à quel lib tu fais appel soit elle a été distribuée et elle est censée être au minimum documentée concernant ses dépendances.

        Et en effet en utilisant strace ca signifie qu'il faut avoir parcouru tout le code ? C'est inutilisable en pratique.

        • [^] # Re: Avantage par rapport à un simple ldd ?

          Posté par  . Évalué à 2.

          Et en effet en utilisant strace ca signifie qu'il faut avoir parcouru tout le code ? C'est inutilisable en pratique.

          Pas pour Soumettre un rapport de bug exécutable permettant sa reproduction chez les développeurs vu que justement tu ne sais pas forcément quelles sont les bibliothèques qui sont chargées chez l'utilisateur.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Avantage par rapport à un simple ldd ?

            Posté par  . Évalué à 1.

            >>"Soumettre un rapport de bug exécutable permettant sa reproduction chez les développeurs"
            Oui, parmi les trois cas d'utilisations possibles cités, c'est celui qui me semble le plus crédible.
            J'ai du mal à trouver d'autre cas.

            • [^] # Re: Avantage par rapport à un simple ldd ?

              Posté par  . Évalué à 7.

              Premier cas : exécuter sur une autre machine sans avoir à compiler les dépendances. C'est l'objectif principal du projet en . Imagine que tu as accès à un cluster de calcul, tu n'as aucune idée de quelle version de bibliothèques vont être installées, ni même s'il va y avoir tout ce dont tu as besoin. Là tu compiles sur une machine de même architecture (ta machine perso, par exemple), tu transfères tout et ça mache

              Deuxième cas (me concerne tout particulièrement). Il exista un jour un logiciel de CAO très bien nommé qcad. https://linuxfr.org/2009/01/15/24874.html Il n'est plus libre, la version dont j'avais besoin n'est plus supportée, et après les années elle ne s'exécute plus sur ma machine (notamment, les libpng et libjpeg ont changé de version majeure). Avec cde, je vais pouvoir ressortir mon vieux disque sur avec une version qui marchait, exécuter cde pour récupérer les vieilles dépendances de bibliothèques, et exécuter ce programme sur ma machine moderne.

    • [^] # Re: Avantage par rapport à un simple ldd ?

      Posté par  . Évalué à 8.

      moi je ferais un simple ldd pour voir les lib requises...
      Mais tu n'obtiens pas tout les fichiers

      pour les fichiers en relation... dans les commentaires de la vidéo, il semble qu'il inclue /etc/passwd...
      C'est sur que s'il récupère tout les fichiers qui sont ouvert, c'est mal barré. Une requête dns et on embarque resolv.conf ?
      On embarque aussi ta conf du jeu ?

      De plus le système de strace est foireux : pour être sur que tout les fichiers sont detectés il faut exécuter tout les chemin de l'appli.
      Par exemple un jeu a plusieurs niveau, et ben il va falloir jouer tout les niveau si l'appli charge les sons/image de manière lazy.


      Et puis CDE c'est déja pris comme nom...

    • [^] # Re: Avantage par rapport à un simple ldd ?

      Posté par  . Évalué à 2.

      Ben moi, au contraire, je trouve le concept effectivement intéressant. Si j'ai bien compris, l'outil ne sert pas qu'à connaître les bibliothèques dépendantes mais aussi à fournir un contexte d'exécution. VMWare fait à peu près pareil avec ThinApp, une virtualisation d'application où le contexte d'exécution est aussi une bulle ou un bac à sable. C'est bien mieux pensé et bien plus efficace qu'une virtualisation complète.

  • # C'est du lourd !

    Posté par  . Évalué à 6.

    J'ai testé avec mon appli écrite en EFL. Le tar.gz prend 380 mo :/

    Du coup c'est pas trop trop utilisable.

    J'ai pas testé si ça fonctionne par contre comme j ai les libs sur mon système. Mais ça a l'air, en tous cas ça se lance.

    • [^] # Re: C'est du lourd !

      Posté par  . Évalué à 3.

      J'ai testé avec mon appli écrite en EFL. Le tar.gz prend 380 mo :/

      Comme les applications pour Windows.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: C'est du lourd !

      Posté par  . Évalué à 2.

      Utilise xz

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

    • [^] # Re: C'est du lourd !

      Posté par  . Évalué à 3.

      Tu pourrais compiler en statique pour inclure juste la portion des EFL que tu utilises. cde s'occuperait des fichiers de conf, de /usr/share/ et des modules chargés dynamiquement.

      Mais sinon ce n'est pas inhabituel que des logiciels un peu complexes embarquent un exemplaire de bibliothèques système. Par exemple le paquet binaire scilab 5.3.0 beta4 fait 140 Mo dont la moitié est une machine virtuelle java.

  • # Windows enfin à portée de Linux

    Posté par  . Évalué à 7.

    ...il fallait que je la fasse :)

  • # Laisser en téléchargement des binaires qui s'exécuteront chez tous le

    Posté par  (site web personnel) . Évalué à 6.

    heu, et linker en statique ça sert à quoi ?

    Il prend pas un peu le problème à l'envers, là ?

    • [^] # Re: Laisser en téléchargement des binaires qui s'exécuteront chez tou

      Posté par  . Évalué à 5.

      Oui tu pourrais mais uniquement si c'est toi qui compiles le logiciel.

      Avec cde, tu peux faire la même chose sur un binaire quelconque. Par exemple, mettons que tu as fait un script bash qui démontre un bug du shell de ta distribution. Tu exécutes le script avec cde, il va capturer le binaire de bash, les dépendances éventuelles, le fichier .bashrc, etc. Tu envoies tout ça aux mainteneurs de ta distribution qui peuvent reproduire le bug sur leur machine.

      • [^] # Re: Laisser en téléchargement des binaires qui s'exécuteront chez tou

        Posté par  (site web personnel) . Évalué à 3.

        oui donc du debug, pas ce qui est sous entendu dans

        Laisser en téléchargement des binaires qui s'exécuteront chez tous les utilisateurs sans qu'ils aient à installer des dépendances, à compiler, ou à installer une machine virtuelle ;

        ton argumentation, que j'ai très bien comprise, revient plutot sur le point:

        Soumettre un rapport de bug exécutable permettant sa reproduction chez les développeurs.

        • [^] # Re: Laisser en téléchargement des binaires qui s'exécuteront chez tou

          Posté par  . Évalué à 2.

          > Laisser en téléchargement des binaires qui s'exécuteront

          Sur la différence avec la compilation statique, voilà ce que l'auteur en dit : « CDE is strictly more powerful than static linking and binary packaging tools, since it can collect run-time dependencies (e.g., configuration files) that programs often require. »

          Et puis tu compiles rarement tout en statique. Par exemple, on peut trouver en téléchargement des binaires de Skype pour plusieurs version de la libc. Ici, cde empaquette aussi la libc.

          • [^] # Re: Laisser en téléchargement des binaires qui s'exécuteront chez tou

            Posté par  . Évalué à 1.

            Ici, cde empaquette aussi la libc.

            Pour pouvoir profiter des mêmes failles de sécurité que celui qui a créé le paquet :-)
            (donc de ce point de vue ça fait "aussi mal" qu'une compilation statique)

            • [^] # Re: Laisser en téléchargement des binaires qui s'exécuteront chez tou

              Posté par  . Évalué à 2.

              Les failles éventuelles dans les libs GNU (compilées en statique ou packagées) ne sont pas le principal danger à craindre quand tu exécutes un binaire provenant de quelqu'un d'autre... (Le programme tout entier pourrait être malicieux, sans avoir besoin de recourir à des éventuels bugs de la libc.) Le seul cas qui pose problème c'est si tu redistribues un logiciel binaire malicieux (sans que tu le saches) encapsulé par cde avec une certaine version de la libc justement vulnérable à une faille exploitée par ce binaire. Les chances que cela se produisent sont faibles, sachant que la personne qui t'a fourni le binaire malicieux ne pouvait pas deviner ta version de la libc.

              Dans tous les cas, le binaire tourne en chroot avec des privilèges bas. Cela procure déjà une certaine sécurité.

    • [^] # Re: Laisser en téléchargement des binaires qui s'exécuteront chez tou

      Posté par  . Évalué à 2.

      Pas si tu as des tas de bibliothèques dynamiques optionelles (plugins etc.) et que tu veux uniquement récupérer celles qui sont réellement utilisées.
      C'est un principe assez connu dans le monde Python, avec des outils comme py2exe ou cx_Freeze.

  • # Existe ?

    Posté par  . Évalué à 2.

    C'est sympa comme truc, mais je me suis souvent demandé : existe il un moyen de combiner ce genre de truc (à savoir, quand on distribue un logiciel, toutes les librairies sont inclus dans le package) avec la méthode traditionnelle (on se sert des librairies du système).

    Par exemple, j'ai un logiciel, quand il se lance il charge la SDL présente sur le système mais il charge OpenAL qui est distribué avec le logiciel parce que je n'ai pas OpenAL d'installé.

    On combine ainsi l'avantage des librairies partagées (occupation de RAM, mise à jour, ...) avec celui de la compilation statique (facile à distribuer).

    Donc ça existe ce genre de trucs ?

    • [^] # Re: Existe ?

      Posté par  . Évalué à -1.

      LD_LIBRARY_PATH ?

      • [^] # Re: Existe ?

        Posté par  (site web personnel) . Évalué à 2.

        Tu peux détailler un peu?

        • [^] # Re: Existe ?

          Posté par  (site web personnel) . Évalué à 1.

          Tu définis la variable d'environnement LD_LIBRARY_PATH=<le chemin des libs que tu empaquetes avec ton soft> dans le shell qui va exécuter le programme que tu veux lancer.

          Ainsi, lorsque le programme va vouloir charger des librairies, il va d'abord les chercher dans les répertoires indiqués dans LD_LIBRARY_PATH. Si il ne trouve pas les libs qui l'intéresse, il va les chercher dans les libraires du système (définit par /etc/ldconfig il me semble).

          Tu peux même créer un "wrapper" qui fait le boulot à ta place.

          Exemple d'un soft ("toto") que tu installes dans ton $HOME. L'exécutable à lancer est toto/bin/toto :

          toto/
          toto/bin/
          toto/bin/toto
          toto/lib/
          toto/lib/toto.so

          Tu te crées un "wrapper" toto/bin/toto.sh , qui fait cela :

          #!/bin/sh
          LD_LIBRARY_PATH=~/toto/lib/
          exec ~/toto/bin/toto

          Et tu lances ~/toto/bin/toto.sh

          • [^] # Re: Existe ?

            Posté par  (site web personnel) . Évalué à 4.

            Ainsi, lorsque le programme va vouloir charger des librairies, il va d'abord les chercher dans les répertoires indiqués dans LD_LIBRARY_PATH. Si il ne trouve pas les libs qui l'intéresse, il va les chercher dans les libraires du système (définit par /etc/ldconfig il me semble).

            Il me semble que c'est exactement l'inverse que sebastienb voulait faire...

            • [^] # Re: Existe ?

              Posté par  . Évalué à 3.

              Ben dans ce cas la il définit LD_LIBRARY_PATH avec en premier les libs systeme et ensuite les libs de son soft ....

              • [^] # Re: Existe ?

                Posté par  (site web personnel) . Évalué à 4.

                Du coup, tu ne peux pas le faire automatiquement, puisque le chemin des librairies du système varie d'un système à l'autre.

                • [^] # Re: Existe ?

                  Posté par  . Évalué à 2.

                  Du coup, tu ne peux pas le faire automatiquement, puisque le chemin des librairies du système varie d'un système à l'autre.
                  Etya pas moyen de récupérer cette info automatiquement ? Je serais surpris que ça ne soit pas possible.

                  • [^] # Re: Existe ?

                    Posté par  . Évalué à 2.

                    Avec ldconfig -v ?
                    (Il faut être root.)

    • [^] # Re: Existe ?

      Posté par  . Évalué à 2.

      Pas trop le temps de detailler mais voici un liens interessant sur le sujet : http://www.gamedev.net/reference/programming/features/linuxp(...)

  • # J'ai oublié...

    Posté par  (site web personnel) . Évalué à 3.

    J'ai la mémoire courte, quelqu'un peut me rappeler les précédentes tentatives d'avoir un tel outil qui se sont soldées par un flop ?

    • [^] # Re: J'ai oublié...

      Posté par  . Évalué à 3.

      Pour la simple distribution de packages (qu'on a compilés soi-même), y'a un truc kde pour tester sans installer, j'ai oublié le nom.

      Pour encapsuler un environnement, tu peux toujours lancer une machine virtuelle mais c'est pas forcément très pratique (c'est comme maintenir deux machines)

      Pour les autres fonctionnalités (packager un binaire quelconque pour qu'il s'exécute de partout), je ne vois pas.

  • # contradictions ?

    Posté par  . Évalué à 2.

    Le binaire ainsi encapsulé est exécutable sur une autre machine [...] la même version majeure du noyau (par exemple 2.6).
    [...]
    Permettre l'exécution de programmes binaires anciens sur des machines récentes, ou le contraire ;[...]

    ce n'est parfois pas le cas si les machines ont trop d'années d'ecart.
    ex : noyau 2.4 au lieu de 2.6

    mais sur des machines pas trop "decalées" ca pourrait le faire

    • [^] # Re: contradictions ?

      Posté par  . Évalué à 5.

      En fait il dit que compiler sur 2.6 et exécuter sur 2.4 ne marche jamais, mais compiler sur 2.4 et exécuter sur 2.6 peut marcher (selon les appels systèmes qui sont passés).

Suivre le flux des commentaires

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