#meta-programming

TL;DR l'ensemble du code de cet article a été compilé en une Rubygem disponible sur Github.

Notre moteur servira à remplacer les expressions entre {{doubles.accolades}} d'un texte par des valeurs. Ces expressions peuvent être un ou plusieurs appels de méthodes successifs. Notre moteur fera cette interpolation à partir d’un contexte qui peut être n’importe quel objet. (Voir les détails de l'implémentation dans les commentaires du code :)

tiny_template.rb

Le constructeur de la classe TinyTemplate prend une chaine qui contient des accolades à interpoler et sa méthode parse reçoit le contexte. On peut l’utiliser de cette manière :

greeting.rb

> Greeting.new "Hello JOHN DOE and welcome to My Fancy Website, your email is [email protected]"

Contrairement à l'interpolation standard en Ruby, notre chaine est une valeur et non du code. Nous pouvons l'enregistrer dans une base de données et laisser l'utilisateur la modifier sans s'exposer à des risques de sécurité. Seules les méthodes publiques et qui ne prennent pas d'arguments peuvent être appelées en chaine.

Se passer du constructeur avec une méthode de classe

Nous pouvons simplifier cette utilisation en passant par une méthode de classe :

tiny_template.rb

Cette méthode de classe instancie TinyTemplate et appelle la méthode d’instance du même nom sur cette nouvelle instance.

greeting.rb

Se passer de parse grâce à une fonction de module

tiny_template.rb

Nous venons de définir une méthode TinyTemplate dans un module inclus en dehors de toute classe ou module. Cela revient à inclure ce module dans Object et rendre ses méthodes universellement accessibles. Nous pouvons dès lors faire :

greeting.rb

Se passer du contexte grâce à la machine à remonter dans le binding !

Nous aimerions rendre le paramètre context optionnel, ou plutôt lui attribuer par défaut la valeur self s'il n'est pas défini. Or, self à l'intérieur de la méthode TinyTemplate(), ou même à sa lisière dans la définition def TinyTemplate(str, context = self) est différent de celui qu'on retrouve à l'extérieur, au niveau de l'appelant.

La valeur de self et de toutes les variables locales définies dans le contexte, de même que toutes les variables de classe ou d'instances à un point donné du code est ce qu'on appelle un binding.

Rien de bien neuf, hein ? Sauf que Ruby permet de capturer le binding à n'importe quel point du code. Il permet même de le passer à d'autres contextes qui peuvent l'examiner et en extraire des données.

La méthode binding de Kernel, accessible dans tous les objets et dans tous les contextes, permet de capturer le contexte en cours dans une instance de la classe Binding.

Cette classe n'offre cependant aucun moyen de lister ou inspecter les éléments de ce contexte. Elle permet en revanche d'y évaluer (exécuter) une chaine de caractère contenant du code Ruby via eval(). En effet, eval prend un deuxième paramètre qui n'est autre que le binding sur lequel sera faite l'évaluation.

Essayons :

discover_binding.rb

Nous avons dit que la classe Binding ne permet pas de lister les variables d'un contexte donné, mais rien ne nous empêche de le faire de l'extérieur grâce à une série d'eval()s sur les méthodes local_variables, instance_variables et global_variables ! Ces méthodes peuvent être appelées de n'importe quel point de code, pourquoi pas sur un binding capturé ? Essayons :

discover_binding.rb

Au passage, soulignons que eval() prend un troisième et un quatrième paramètre qui sont respectivement le nom du fichier et le numéro de ligne qui seront rapportés. L'usage est d'y passer les constantes "magiques" __FILE__ et __LINE__, ce qui permettra de guider le débogueur vers l'endroit de l'évaluation, en cas d'erreur de syntaxe.

D'après ce qu'on vient d'apprendre, nous pouvons passer le binding de l'appelant à TinyTemplate et utiliser ce binding pour évaluer self.

Et l'appeler ainsi : TinyTemplate(self, binding).

Sauf que cela ne nous a été d'aucune utilité. On a remplacé la variable context par caller_binding et on a dû ajouter un traitement supplémentaire sans rendre optionnel le paramètre context. Il nous faut un moyen d'accéder aux bindings précédents.

Ruby 2 et plus précisément MRI, l'implémentation officielle de Ruby (oui, car il y'en a plusieurs !) a rendu cela possible. Son API debug_inspector peut être utilisée pour remonter dans la pile des bindings précédents.

Rendons le paramètre context de TinyTemplate() optionnel. Dans le cas où il est omis, nous retrouvons le contexte de l’appelant à l'aide de RubyVM::DebugInspector.

tiny_template.rb

À ce point nous pouvons faire :

greeting.rb

Les bindings sont rarement manipulés explicitement en production. Mais la réalité est qu'ils sont partout utilisés dans nos codes. Les blocks Ruby et autres éléments de langages exécutables (procs et lambas) capturent automatiquement le binding où ils sont créés. Ce qui en fait des closures, des fermetures en bon français. L'exécution de leur code se fait dans un mix entre ce binding capturé automatiquement et celui où ils sont exécutés via .call ou yield.

Le binding d'un proc peut être accédé comme ça : proc{}.binding. Cette syntaxe peut notamment servir à accéder à une information située à l'extérieur d'un block passé à instance_eval. Mais ce n'est pas là notre sujet. Reprenons maintenant l'expérimentation :

Se débarrasser de “TinyTemplate” grâce aux open classes

Aurions-nous le moyen de raccourcir davantage cette syntaxe ? Oui, en utilisant un objet existant, qui n’est autre que la chaine de caractère du template à parser !

tiny_template.rb

En effet, Ruby nous permet d’ouvrir des classes existantes et d’y ajouter des méthodes : 

greeting.rb

Attendez, pour le coup on a dû rétablir .parse, mais pas pour longtemps : 

Se (re)débarasser de parse grâce à une méthode-opérateur

.parse c’est six caractères, il y a moyen de les réduire à un (1) seul, qui se placera devant la chaine à parser !

tiny_template.rb

Nous avons aliasé “~” (le caractère tilde, qui sert généralement à inverser le bit logique ou matcher des expressions régulières) à parse. Oui, c’est possible, car en Ruby, les opérateurs ne sont que des méthodes. Cela peut être fait également pour +, -, /, *, !, |, & et tous les autres opérateurs. Le tilde est un opérateur unaire, il ne prend qu'un seul paramètre, qui se trouve être self dans notre exemple.

Voici donc l'utilisation définitive :

greeting.rb

Conclusion

Je suis particulièrement content d'avoir pu parler des binding sur ce blog, car il est difficile de trouver un exemple real-life utile de leur utilisation directe. On n'a habituellement pas besoin de s'en préoccuper. C'est les outils de débogage et d'introspection de code comme pry ou better errors qui en font le plus usage.

Privilégier les API et les couches d'abstraction

À cause de ces risques, il est préférable de communiquer avec les différents services via des API, même au sein d'un même système. C'est possible avec ElasticSearch ou Redis par exemple, qui font tout passer par des endpoint sous localhost.

Mais les outils qui proposent des API restent rares, préférez alors une couche d'abstraction en Ruby qui vous évite de préparer manuellement des commandes paramétrées. Et assurez-vous que cette couche gère de manière optimale la sanitization des paramètres. Si vous ne trouvez pas de couche d'abstraction, écrivez en une si possible, mais laissez la solution de préparer des commandes en dernier recours.

Appeler une commande système en Ruby, divers moyens nuancés

Il existe plusieurs moyens d'exécuter des commandes système en Ruby. S'ils semblent identiques ou interchangeables, il y a des nuances dans leur mode d'exécution et leurs valeurs de retour.

Le module Kernel, inclus dans Object et dont les méthodes sont par conséquent accessibles à tous les objets Ruby, inclut trois méthodes qui exécutent des commandes système : Kernel#`, Kernel#exec, Kernel#system.

1 - Kernel#` (remarquez le petit backstick après le dièse) exécute la commande dans un subshell (un processus enfant) et renvoie la sortie standard de la commande. Cette méthode est appelée via la syntaxe spéciale `commande` mais rien ne nous empêche de l'appeler plus conventionnellement via send.

> send('`', 'ls') => "Gemfile\nGemfile.lock\nREADME.rdoc\nRakefile\napp\nbin\nconfig\nconfig.ru\ndb\nlib\nlog\npublic\ntest\ntmp\nvendor\n"

C'est également cette méthode qui est appelée avec la syntaxe %x{commande} :

> %x{ls} => "Gemfile\nGemfile.lock\nREADME.rdoc\nRakefile\napp\nbin\nconfig\nconfig.ru\ndb\nlib\nlog\npublic\ntest\ntmp\nvendor\n"

2 - Kernel#system exécute la commande dans un subshell (comme `) mais renvoie le statut d'exécution, résumé en soit true soit false (ou nil pour les commandes inexistantes). L'exit-code de la dernière commande exécutée reste accessible dans la variable globale $? avant qu'il ne soit remplacé par le code de la prochaine commande système exécutée. system renvoie true uniquement si l'exit code de la commande est de 0.

> system('pwd') /Users/Ihcene/aritylabs/secure_shell => true

system se distingue également de ` par la possibilité de recevoir des variables d'environnement et des paramètres supplémentaires.

3 - Kernel#exec exécute la commande en remplaçant le processus actuel. L'exécution de votre code est donc interrompue pour de bon et il n'est pas possible de tester la valeur de retour ni d'inspecter les sorties standards. exec prend les mêmes paramètres que system.

Il existe d'autres moyens d'exécuter des commandes comme IO#popen et Open3#popen3. Ces derniers permettent un contrôle avancé des flux d'entrée de sortie et d'erreurs, mais nous nous intéresserons plus spécialement à Kernel#` pour la suite de cet article.

Sécuriser les commandes avec Shellwords

Sécuriser une commande est très simple : il suffit d'échapper les paramètres de sources pas sûres à l'aide de Shellwords, un module de la bibliothèque standard de Ruby, qui respecte la norme POSIX / SUSv3.

> require 'shellwords' => true > params = {file: 'Gemfile ; rm -rf /'} > `grep rails #{Shellwords.escape( params[:file] )}` grep: Gemfile ; rm -rf /: No such file or directory => ""

Notons que require 'shellwords' ouvre la classe String pour y insérer des raccourcis commodes. Nous aurions pu faire :

> `grep rails #{ params[:file].shellescape )}`

Mais encore faut-il se souvenir d'échapper chaque paramètre ajouté de chaque appel de fonction. Un seul oublie et tout est compromis. C'est pourquoi nous allons élaborer une solution de tolérance zéro.

Suspecter toutes les commandes

Ouvrons d'abord la class String pour ajouter le moyen de reconnaitre si une chaine est sûre ou non. Utilisons ce moyen pour marquer les chaines échappées comme étant sûres.

secure_shell.rb

Maintenant, nous devons intervenir sur le module Kernel pour désigner qu'il n'accepte que les chaines échappées ou désignées explicitement comme sûres. Faisons celà par monkey patching classique. Le code peut sembler bizarre avec toutes les apostrophes inversées, mais il est pleinement fonctionnel.

secure_shell.rb

Nous allons à présent apporter quelques modifications de la classe String afin de permettre la création de chaines sûres par la concaténation d'autres chaines sûres. Pour cela, nous ferons du Monkey Patching d'une approche différente : au lieu de renommer et remplacer les méthodes voulues, nous prependront un module avec de nouvelles versions de nos méthodes : 

secure_shell.rb

Essayons pour voir : 

> ("grep rails".shell_safe! + params[:file].shellescape).shell_safe? => true

Mais notre solution n'est pas utilisable en l'état. La syntaxe du backstick `cmd` ne prend pas de variable et nous oblige de passer par des interpolations. Après des heures de recherches et de lecture de code C, j'ai conclu que l'interpolation de chaines en Ruby est effectuée en bas niveau sans appeler des méthodes surchargeables de la classe String ou autre. On est en effet en droit de croire que "grep #{params[:keyword]} Gemfile" n'est qu'un sucre syntaxique pour "grep " + params[:keyword] + " Gemfile", mais il n'en est malheureusement rien !

Nous allons donc être forcés d'utiliser la syntaxe send('`', "grep #{params[:keyword].shellescape} Gemfile".shell_safe!) ou créer une autre méthode dans kernel. C'est ce que nous allons faire en aliasant backstick à ` : 

secure_shell.rb

> backstick("grep ".shell_safe! + params[:keyword].shellescape + " Gemfile".shell_safe!) => "..."

Si nous oublions d'échapper l'une des chaine ou d'en désigner explicitement l'une comme étant saine, une exception est soulevée.

> backstick("grep ".shell_safe! + params[:file].shellescape + " Gemfile") ArgumentError: Unsafe command, please use String#shellescape or String#shell_safe!

Refinements

Notre exemple illustre parfaitement les dangers du monkey patching. En modifiant le comportement des méthodes, on s'expose au risque de compromettre d'autres codes qui les utilisent.

Si les autres dépendances de votre application (gems) font des appels de commandes système, et c'est toujours le cas, des erreurs surgiront de partout.

C'est la problématique que les refinements introduits dès Ruby 2 sont venus combler. Découverte.

Les refinements permettent de limiter les modifications des classes à des scopes définis (module, class, bloc begin ; end, etc.).

Pour les utiliser, nous devons englober toutes nos ouvertures de classes dans un module. Nous devons également changer d'approche pour la réouverture de modules. refine ne marche en effet qu'avec des classes : 

secure_shell.rb

La modification des méthodes de Kernel se fait maintenant par la simple inclusion d'un module. Nous n'avons pas besoin d'utiliser prepend ici car nous savons que Kernel est inclut dans Object. Kernel est donc l'un des ancêtres de Objet. Le dernier module inclut dans une classe est placée en tête de liste des ancêtres. SecureShell::KernelMethods passe donc devant Kernel et peut par conséquent utiliser ses méthodes via `super`.

L'utilisation des refinements se fait à l'aide du mot clé using, qui n'est, sans surprise, qu'une méthode de la class Module. Essayons : 

> irb >> $: << '.' >> require 'secure_shell' >> "aString".shell_safe? NoMethodError: undefined method `shell_safe?' for "aString":String >> begin  >>   using SecureShell >>   puts "aString".shell_safe?  >> end  => false >> "aString".shell_safe? NoMethodError: undefined method `shell_safe?' for "aString":String

Nous utilisons irb pour tester notre solution, la première ligne ajoute le dossier en cours au load_path de Ruby, ce qui nous permet de require le code du refinement. Notez comment l'utilisation de la méthode shell.safe? en dehors du bloc begin / end échoue.

Faisons maintenant des appels plus avancés :

> irb >> $: >> require 'secure_shell' >> require 'securerandom' >> begin >>   using SecureShell >> >>   backstick('git init '.shell_safe! + SecureRandom.hex(20).shellescape) >> end NoMethodError: undefined method `shell_safe?' for "git init ":String   from /Users/Ihcene/aritylabs/secure_shell/secure_shell.rb:48:in `+'

Erreur ! Nous constatons que "git init ".shell_safe! fonctionne mais pas l'appel à shell_safe? situé dans notre surcharge de la méthode :+ de String via SecureShell::StringConcat. Il est vrai que ce module est inclus dans String mais il ne bénéficie pas, lui, du refinement dont il fait pourtant partie. Nous venons d'être témoin du caractère très strict par rapport au scope des Refinements, qui fait leur force.

La solution est d'isoler les méthodes #shell_safe!, #shell_safe? et #shellescape dans un refinement imbriqué, qui sera utilisé dans le refinement global lui-même et dans les scopes qui nécessitent de sécuriser les appels de commandes système :

secure_shell.rb

L'ensemble peut être utilisé sur une classe de cette manière :

gist.id

> Gist.new.create => "Initialized empty Git repository in /Users/Ihcene/aritylabs/secure_shell/ecc8984c07440cecfc0badbd02bea560e9c58b1b/.git/\n"

Conclusion