Packaging sans droit root

Les PortablesApps sur Windows

A contrario, on observera attentivement comment se comporte l’installateur Google Chrome sur Windows. Celui-ci essaie bien également de s’installer pour tous les utilisateurs mais s’il observe qu’il ne dispose pas de droit privilégié, il propose de s’établir dans les répertoires de l’utilisateur courant et fonctionne sans difficulté, y compris pour les mises à jour automatiques. C’est d’autant plus astucieux qu’on sait bien qu’un PC a rarement plus d’un utilisateur réel au quotidien : le risque de duplication est donc quasi-inexistant.

Ce fait est largement ignoré du grand public comme me l’avait démontré un quiproquo avec un DSI il y quelques années. A la question « combien de personnes utilisent Chrome dans votre parc (environ 8000 PC) », il répondit interloqué qu’il ne pouvait y en avoir puisque seuls Internet Explorer et Firefox étaient installés sur les PC. En réalité, les logs des proxys ont rapidement démontré que la plupart des agents de la DSI, entre autres, avaient très bien su adopter le navigateur devenu dominant.
Pour généraliser, il existe depuis une décennie un écosystème de PortableApps qui permettent de stocker des applications pour Windows juste sur une clé mémoire USB ou un répertoire personnel. Ce packaging répond notamment au besoin de séparer les activités Professionnelles et Personnelles, en utilisant un même PC, en particulier dans les pays où l’équipement dans les foyers n’est pas aussi important qu’en Europe.

Quel intérêt sur les serveurs ?

Sur les serveurs, les pratiques évoluent plus lentement mais on observe des frémissements. D’un côté, des langages Go, Rust ou Zig y participent en tant que langages compilés produisant des binaires monolithiques directement exécutables, mais les usages ont la vie dure : alors qu’un serveur, (devenu virtuel) a généralement un usage unique, on continue à utiliser les concepts établis dans des machines physiques en temps partagé.
Pourtant il y a un intérêt majeur pour les développeurs à faire une croix sur les droits root. Par définition, quand un développeur réclame des droits root, il exige la cogestion et la suppression de la barrière entre lui et le gestionnaire de la plateforme, que cela soit un PC ou un serveur. Quand l’utilisateur est aussi le propriétaire de l’équipement et son exploitant [1] , tout cela n’est que subtilité mais cela n’est plus un détail dans une organisation qui gère des parcs machines et où les gestionnaires d’infrastructures sont responsabilisés sur la disponibilité du parc.

En réalité, de Linux à Windows en passant par macOS, les systèmes d’exploitation ont déjà pour vocation d’être des plateformes pour exécuter des programmes, en permettant de faire abstraction des détails de la machine : pilote d’imprimante ou de carte graphique, taille des disques et organisation des volumes de stockage, etc. Exécuter une application ne nécessite pas d’autre chose d’un utilisateur que de récupérer le binaire et de le lancer, même si le processus a été complexifié au cours des dix dernières années avec des marquages de quarantaine pour les téléchargements depuis Internet ou clés USB pour lutter contre les maliciels.
Le besoin « d’installer » un programme n’existe que si on veut le rendre utilisable pour tous les utilisateurs du PC ou du serveur. C’est pour accéder à des ressources partagées avec d’autres utilisateurs (des répertoires comme /usr/bin, /usr/local ) que l’OS réclame des droits d’administration. Si on exclut les applications de VPN (et encore…), l’immense majorité des programmes n’ont besoin d’aucune ressource partagée d’un serveur [2] : un gestionnaire de base de données aussi sophistiqué que Postgres créée de nombreux process mais il ne consomme que des ressources privées, fichiers d’un côté, sockets et ports TCP de l’autre.
Rationnellement, iI y a donc très peu de chance que l’hébergeur final de l’application accepte la cogestion des machines ; on ne l’observe d’ailleurs pas chez les hébergeurs ou éditeurs commerciaux. Pour vous donner la liberté réclamée, la plateforme sera obligée de recréer une couche de virtualisation où le gestionnaire sera seul maitre de l’infra et l’utilisateur du supra. Pour le packaging par conteneurs, c’est « l’astuce » de podman rootless avec slirp4netns
Donc, si un développeur veut que son application s’exécute sans difficulté sur toute la chaîne de livraison continue, depuis sa machine de développement, les fermes de compilation et de test, jusqu’aux déploiements dans les différents environnements, il a donc intérêt à internaliser les prérequis d’exécution sans droit privilégié. Son packaging applicatif et ses scripts de mise en place devraient fonctionner sans droit ‘root’.

Et concrètement ?

Habitué à son PC autogéré, un développeur aimerait évidemment utiliser le packaging traditionnel des distributions Linux, apt ou rpm. Mais il existe de nouvelles alternatives. Homebrew a montré la voix sur macOS, même si pour la petite histoire, Google n’a pas su reconnaître la valeur ajoutée de son créateur Max Howell à ses propres équipes.
Sur Linux, les alternatives se multiplient, de tea.xyz le petit dernier du même Howell, webinstall ou le vénérable Nix créé en 2003 déjà. Une autre approche consiste à intégrer le runtime à la plateforme qu’il s’agisse d’une Java Virtual Machine ou Docker Engine.
Dans tous les cas, les développeurs ont tout intérêt à affiner leur maitrise du packaging : l’avenir est sans doute plus rootless que serverless.