Forum Programmation.shell Lister les commandes appelées par un script

Posté par  .
Étiquettes : aucune
5
18
sept.
2010
Salut,

J'ai une collection de scripts en sh "pur" et j'aimerai extraire la liste de toutes les commandes externes appelées afin de "valider" l'environnement d'exécution.

Bon je peut faire un programme pour développer les variables et lister tout les premiers mots en début de ligne ou après un ";", "|", "&", entre "``" ou "$()" (à moins que ce dernier soit un bashism)... puis supprimer les mots réservés, les fonctions... Mais si il existe déjà un programme pour faire ça ou un shell avec quelques fonctions étendues pour les développeurs qui le permette ce n'est pas de refus et ça évitera les oublis.

  • # strace

    Posté par  . Évalué à 2.

    Un truc du genre (non testé)
    strace -f -e execve 2>&1 | cut -d "\"" -f2

    • [^] # Re: strace

      Posté par  . Évalué à 3.

      Il m'a zappé le script...
      strace -f -e execve script.sh 2>&1 | cut -d "\"" -f2

      • [^] # Re: strace

        Posté par  . Évalué à 6.

        Le problème c'est que c'est que tu dois être sûr d'avoir une couverture de code complète lors de tes exécutions.

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

        • [^] # Re: strace

          Posté par  . Évalué à 1.

          En effet...
          Mais dans le cas général je ne pense pas que ce soit possible.
          Une analyse statique ne permettra pas de couvrir les cas où le nom/chemin de l'exécutable appelé dépend de la valeur d'une variable.
          Quelques pistes tout de même :
          - apparemment il existe une option -rpm-requires dans certaines versions de bash qui liste des dépendances (mais elle n'est pas exhaustive en partie pour les raisons évoquées plus haut)
          - en utilisant un compilateur pour bash il doit y avoir moyen d'arriver à quelque chose à partir du code généré
          - sinon il reste l'écriture d'un parseur ad-hoc, mais ça risque de ne pas être marrant (et il ne sera pas non plus exhaustif)

          En tout cas c'est un problème intéressant ;-)

          • [^] # Re: strace

            Posté par  . Évalué à 5.

            Je m'y suis penché à une époque mais je n'ai pas abouti à quelque chose d'intéressant : le problème est complexe, on peut avoir des scripts qui appellent d'autres scripts ou qui sourcent un autre fichier.

            • [^] # Re: strace

              Posté par  . Évalué à 1.

              Merci à tous déjà

              Sûr c'est complexe, je vais voir un peu tout ça et essayer de faire un truc qui dégrossisse au moins un peu le boulot.

        • [^] # Re: strace

          Posté par  . Évalué à 3.

          Il y a aussi le problème que ça exécute le script. Si son but est, par exemple, de justement vérifier que le script n'utilise pas une certaine commande, ça peut faire des dégats. Il y a aussi d'autres raisons qui font que ce n'est pas forcément bon d'exécuter le script.

          • [^] # Re: strace

            Posté par  . Évalué à 1.

            D'où les différentes options de sécurité de eix (programme d'indexation des paquets de Gentoo) en fonction du niveau de confiance attribué aux ebuilds. La lecture du code de ce programme me donnera peut-être quelques pistes à creuser !

            D'un autre coté je ne vois trop comment développer ça sans exécuter le code :

            IPT=`which iptables`

  • # C'est un problème indécidable

    Posté par  . Évalué à 6.

    Il me semble que c'est un problème indécidable, donc même si tu peux trouver un algo qui va te lister les commandes dans la majorité des cas (et qui couvrira probablement largement tout ce qui t'intéresse) il existera toujours un moyen d'outrepasser cette vérification par un moyen (très) détourné.

    • [^] # Re: C'est un problème indécidable

      Posté par  . Évalué à 4.

      Un exemple parmi 174158157215545:
      $ V1=l;V2=s;eval $V1$V2 /
      Résultat:
      bin cdrom etc initrd lib media opt root srv tmp var boot dev home initrd.img lost+found mnt proc sbin sys usr vmlinuz

      • [^] # Re: C'est un problème indécidable

        Posté par  . Évalué à 4.

        C'est clair qu'avec eval, cela est bien plus flagrant. Bien que dans ton exemple, l'eval est complètement inutile :P

        • [^] # Re: C'est un problème indécidable

          Posté par  . Évalué à 3.

          dans ton exemple, l'eval est complètement inutile
          Je suis tellement calé en shell que je n'avais jamais fait attention à ça :-)

  • # chroot + exécution

    Posté par  . Évalué à 3.

    je pense qu'il y a consensus pour conclure qu'en analyse statique, c'est très ardu (voire impossible).

    pour avoir une chance d'être exhaustif en dynamique, comme le dit Barret Michel, ça suppose d'avoir des tests ayant la plus large couverture possible.

    si je devais lister toutes les commandes externes d'un script, je monterais un environnement chrooté avec simplement un bash, et je compléterais cet environnement à mesure que je rencontrerais des "command not found".

    Ensuite, dans une perspective à long terme, tous les nouveaux scripts devraient être validés dans cet environnement avant le déploiement.

Suivre le flux des commentaires

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