Systemd 256 : un rapport de bogue indique que systemd-tmpfiles pourrait effacer de manière inattendue votre répertoire /home

Les mainteneurs sortent Systemd 256.1 avec des mises en garde sur l'option '-purge'

Un rapport de bogue pour systemd a révélé que la commande systemd-tmpfiles --purge ne se contente pas de supprimer les fichiers temporaires, mais peut également effacer tout le répertoire /home. La mise à jour de la commande a été demandée, avec une mise en garde claire concernant l’option –purge. Après des discussions, systemd-tmpfiles a été amélioré pour accepter un fichier de configuration lors de l’exécution de la commande purge, obligeant ainsi l’utilisateur à spécifier les fichiers à supprimer. La documentation a également été améliorée pour clarifier ce comportement.

Systemd, le système d’initialisation largement utilisé dans les distributions Linux modernes, a récemment fait face à une controverse concernant la commande systemd-tmpfiles. Un rapport de bogue a révélé que cette commande pouvait non seulement supprimer les fichiers temporaires, mais également effacer tout le répertoire /home de l’utilisateur.

Le problème

Lorsqu’un utilisateur exécute la commande systemd-tmpfiles --purge, l’objectif est de nettoyer les fichiers temporaires. Cependant, il a été découvert que cette commande pouvait également supprimer tout le contenu du répertoire /home de l’utilisateur. Imaginez la surprise d’un utilisateur qui a exécuté cette commande et a constaté qu’une bonne partie de son répertoire personnel avait disparu !

L'utilisateur de GitHub jedenastka a écrit un rapport indiquant la situation, même si les mainteneurs de systemd ont fait des réponses qui pourraient être résumées par « vous vous y prenez mal ».

Voici ce que jedenastka décrit dans la section « comportement inattendu que vous avez vu »

De nombreux messages d'avertissement ont commencé à apparaître, y compris des chemins dans /home (il ne pouvait pas restaurer les temps de modification... ?). Qu'est-ce qu'un outil de nettoyage temporaire fait dans mon répertoire personnel ? Ce n'est pas bon. Mon cœur s'est mis à battre plus vite et j'ai appuyé sur Ctrl-C aussi vite que possible.

Il s'avère qu'une bonne partie de mon répertoire personnel a été supprimée. Heureusement, il semble que cela ait commencé par les fichiers de configuration et non par les données proprement dites, mais je ne suis toujours pas sûr d'avoir perdu quoi que ce soit d'important. J'ai éteint la machine pour récupérer les données plus tard avec extundelete (ça n'a pas marché, ça plante instantanément pour une raison ou une autre ; j'ai des sauvegardes, mais elles sont un peu dépassées, je remplis les disques beaucoup trop vite).

J'en ai parlé sur #debian-next, et il semble que ce ne soit pas un bug, mais une fonctionnalité, car systemd-tmpfiles gère également la création automatique de répertoires de données tels que /home, et l'option --purge est destinée à les nettoyer. Je ne sais pas quelle est l'utilité de cela, mais je suppose qu'il y a une bonne raison.

Ce qui me pose problème, c'est la documentation. Elle explique ce que font les options, techniquement parlant (enfin, je le suppose - je n'en sais pas beaucoup sur l'architecture ici), mais elle n'explique pas pourquoi elles font ce qu'elles font. En parcourant la documentation, les trois options semblent faire la même chose - nettoyer les fichiers temporaires, bien que --purge semble "plus complet" car il mentionne qu'il supprime tous les fichiers (y compris les données de l'utilisateur).

Cela nous ramène en quelque sorte à la section « Comportement attendu que vous n'avez pas vu », mais parfois la forme rigide des modèles de questions ne s'adapte pas à tout - donc, ce que je voudrais voir est :

1. Une explication de la raison pour laquelle une option donnée fait quelque chose, par exemple :

En tant qu'utilisateur, je ne sais pas à quoi ils sont destinés, mais en tant que développeurs, vous le savez probablement, et pouvez les décrire mieux que je ne l'ai fait Je ne pense pas que cela soit spécifique à systemd-tmpfiles, cela devrait probablement être utilisé comme une ligne directrice sur la façon d'écrire des manuels à l'échelle du projet (et honnêtement, à l'échelle de l'industrie).

2. Un énorme avertissement à côté de --purge. Cette option est dangereuse, il faut donc l'indiquer clairement. hdparm(8) en est un bon exemple :

Pour moi, ce serait suffisant, car je vérifie les options que j'utilise dans le manuel. Je ne suis pas sûr qu'il faille une confirmation ou autre, je ne pense pas que ce soit nécessaire, même si vous avez une confirmation, certaines personnes confirmeront aveuglément de toute façon. Avoir une confirmation serait aussi une rupture de l'API, je suppose.

Dans un premier temps, le rapport de bogue a été rejeté par Luca Boccassi, développeur de systemd chez Microsoft


Mais l'équipe se ravise et apporte une mise à jour

En dépit d'une réponse initialement plutôt hostile selon laquelle la commande ne faisait que ce qui était indiqué sur la boîte, qu'il fallait toujours lire l'étiquette etc, cette commande a maintenant donné lieu à quelques avertissements supplémentaires.

En effet, après de nombreuses discussions qui ont duré des jours, le comportement de systemd-tmpfiles a été amélioré. Ce patch a été fusionné et permet à systemd-tmpfiles d'accepter un fichier de configuration lors de l'exécution de purge. De cette façon, l'utilisateur doit fournir en connaissance de cause le(s) fichier(s) de configuration duquel (desquels) il souhaite que les fichiers soient supprimés. La documentation a également été améliorée pour rendre le comportement plus clair.

Ce correctif a été intégré dans la version point de systemd 256.1.

En clair, désormais, la sous-commande --purge insiste sur un fichier de spécification, le résumé de la commande est plus explicite et recommande la prudence, il y a un avertissement dans la page de manuel, et la description de l'outil systemd-tmpfiles ne contient plus le mot "temporaire". Ce n'est pas grand chose, mais c'est déjà ça. Cela fait partie d'autres changements modestes, bien sûr.

C'est un rappel utile à toutes les personnes concernées. Étant tous très occupés, tout le monde n'a pas le temps de lire la documentation en entier à chaque fois. Les noms ont de l'importance, et le reste du monde ne remarquera probablement pas que vous modifiez la fonction d'un outil si son nom fait toujours référence à une définition désormais obsolète.

Conclusion

Cette situation soulève des questions plus larges sur la transparence des logiciels open source. Les utilisateurs doivent-ils s’attendre à ce que des commandes apparemment inoffensives puissent avoir des conséquences désastreuses ? Les développeurs doivent-ils être plus prudents lorsqu’ils conçoivent des outils système ?

La version 256.1 de Systemd a corrigé le problème de suppression inattendue du répertoire /home par systemd-tmpfiles. Cependant, cette controverse nous rappelle l’importance de la vigilance et de la communication entre les développeurs et les utilisateurs. Espérons que cette expérience conduira à des pratiques plus sûres et à une meilleure compréhension des risques potentiels dans le monde des logiciels open source.

Sources : GitHub, systemd v256.1

Et vous ?

Pensez-vous que la suppression inattendue du répertoire /home par systemd-tmpfiles est un problème sérieux ? Avez-vous déjà rencontré ce problème ou connaissez-vous quelqu’un qui l’a vécu ?
Quelles mesures pensez-vous que les développeurs de systemd auraient dû prendre pour éviter ce problème ? Évoquez les solutions possibles et partagez vos idées ?
Est-ce que cette vulnérabilité affecte votre utilisation quotidienne de systemd ? Avez-vous / allez-vous modifier votre comportement suite à cette découverte ?
Pensez-vous que les logiciels open source devraient être plus transparents concernant les risques potentiels ? Explorez la question de la responsabilité des développeurs et de la communication avec les utilisateurs.
Quelles autres fonctionnalités ou comportements de systemd méritent d’être discutés ? Élargissez la discussion au-delà de ce cas spécifique.