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

Posté par Tonton Benoit le 18 septembre 2010 à 03:29.

Étiquettes : aucune

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 neologix le 18 septembre 2010 à 13:02. Évalué à 2.

Un truc du genre (non testé)
strace -f -e execve 2>&1 | cut -d "\"" -f2
- [^] # Re: strace
  
  Posté par neologix le 18 septembre 2010 à 13:04. Évalué à 3.
  
  Il m'a zappé le script...
  strace -f -e execve script.sh 2>&1 | cut -d "\"" -f2
  - [^] # Re: strace
    
    Posté par barmic le 18 septembre 2010 à 13:38. É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 neologix le 18 septembre 2010 à 15:00. É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 totof2000 le 18 septembre 2010 à 15:36. É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 Tonton Benoit le 18 septembre 2010 à 16:32. É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 skeespin (site web personnel) le 20 septembre 2010 à 18:58. Évalué à 1.
        
        ça ressemble à l'utilisation du "set -x"
    - [^] # Re: strace
      
      Posté par KiKouN le 18 septembre 2010 à 16:24. É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 Tonton Benoit le 18 septembre 2010 à 16:39. É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 benoar le 19 septembre 2010 à 16:09. É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 Kerro le 19 septembre 2010 à 17:08. É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 benja le 19 septembre 2010 à 18:25. É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 Kerro le 19 septembre 2010 à 19:01. É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 gaaaaaAab le 20 septembre 2010 à 14:47. É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.