Technique | Utiliser du Python côté serveur

Par Jean-Christophe Arnu le 30/09/2004 - 15:39

Python est un langage largement utilisé de nos jours. Il permet de s'interfacer avec un grand nombre de bases de données et PostgreSQL n'échappe pas à la règle. Bien que Python soit connu pour le développement de requêtage des serveurs PostgreSQL (applications, maintenance, ...), un support est aussi intégré «côté serveur» dans PostgreSQL. Hors, dans le « ChangeLog Â» de la version de 7.4 de PostgreSQL (version 7.4 du changelog également), on trouve la petite phrase suivante dans la section « côté serveur Â» :

Make PL/Python an untrusted language, now called plpythonu (Kevin Jacobs, Tom)

The Python language no longer supports a restricted execution environment,

so the trusted version of PL/Python was removed. If this situation changes,

a version of PL/Python that can be used by non-superusers will be readded.

Comme il y est dit, Python ne supporte plus un environnement d'exécution restreint et, de ce fait, PostgreSQL ne supporte plus Python (ou PL/Python) comme langage «accrédité». Mais quel est cet environnement d'exécution restreint en Python ? Qu'est-ce qu'un langage « accrédité Â» ? Pourquoi les développeurs de PostgreSQL ont décidé de placer Python en langage « non accrédité Â» et qu'est-ce que cela implique ?

Python est un langage script relativement répandu et répondant à un grand nombre de problématique. Comme tout langage de cette génération, Python intégrait la possibilité de lancer des scripts chargés dynamiquement à l'intérieur d'un environnement d'exécution où certaines fonctionnalités seraient permises et où d'autres seraient inaccessibles. Cette fonctionnalité d'environnement restreint permettait donc de rendre l'application qui l'implantait capable de limiter les actions des utilisateurs et de rendre l'application plus robuste vis à vis de l'ingéniosité de ces derniers. Plusieurs environnements Python d'exécution restreinte existent comme rexec ou Bastion. Jusqu'à récemment, PostgreSQL utilisait rexec mais les développeurs de Python ont décidé de rendre ces modules inactifs dans les version 2.2 et 2.3 de Python (voir [1]). En effet, plusieurs failles dans ces modules ont été trouvées (voir le fil de discussion commençant par [2]). Reste à savoir pourquoi l'équipe PostgreSQL a fait le choix de placer Python en langage non accrédité.

PostgreSQL permet d'utiliser plusieurs langages dans les procédures stockées, les déclencheurs, etc... Chaque langage côté serveur dispose donc d'une entrée dans une table pg_language et de permissions d'exécution. Il existe, sans trop rentrer dans les détails, deux types de langages : les langages dits « accrédités Â» (trusted) qui ont la possibilité d'être exécutés par n'importe quel utilisateur sans restriction et les langages « non accrédités Â» (untrusted) qui ne peuvent être exécutés que par le super utilisateur de la base (souvent il s'agit de l'utilisateur postgres). Ainsi donc, Python est devenu un langage «non accrédité» car l'environnement d'exécution restreint de Python utilisé par PostgreSQL n'était de toute évidence pas sûr. L'équipe PostgreSQL a donc préféré laisser la fonctionnalité Pl/Python mais avec certaines restriction sur son utilisation. Seul le super utilisateur aura donc la possibilité d'utiliser ce langage. Pour plus d'information sur Pl/Python, je vous conseille la lecture de [3] (des volontaires pour faire la traduction ?).

Pour conclure, nous pouvons souhaiter que Python réintègre rapidement un environnement d'exécution limité de manière à ce que les utilisateurs puissent bénéficier de la puissance de ce langage sur PostgreSQL et côté serveur.