Un rapport de bogue pour systemd a rvl que la commande systemd-tmpfiles –purge ne se contente pas de supprimer les fichiers temporaires, mais peut galement effacer tout le rpertoire /home. La mise jour de la commande a t demande, avec une mise en garde claire concernant loption purge. Aprs des discussions, systemd-tmpfiles a t amlior pour accepter un fichier de configuration lors de lexcution de la commande purge, obligeant ainsi lutilisateur spcifier les fichiers supprimer. La documentation a galement t amliore pour clarifier ce comportement.
Systemd, le systme dinitialisation largement utilis dans les distributions Linux modernes, a rcemment fait face une controverse concernant la commande systemd-tmpfiles. Un rapport de bogue a rvl que cette commande pouvait non seulement supprimer les fichiers temporaires, mais galement effacer tout le rpertoire /home de lutilisateur.
Le problme
Lorsquun utilisateur excute la commande systemd-tmpfiles –purge, lobjectif est de nettoyer les fichiers temporaires. Cependant, il a t dcouvert que cette commande pouvait galement supprimer tout le contenu du rpertoire /home de lutilisateur. Imaginez la surprise dun utilisateur qui a excut cette commande et a constat quune bonne partie de son rpertoire personnel avait disparu !
L’utilisateur de GitHub jedenastka a crit un rapport indiquant la situation, mme si les mainteneurs de systemd ont fait des rponses qui pourraient tre rsumes par vous vous y prenez mal .
Voici ce que jedenastka dcrit dans la section comportement inattendu que vous avez vu
De nombreux messages d’avertissement ont commenc apparatre, 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 rpertoire personnel ? Ce n’est pas bon. Mon cur s’est mis battre plus vite et j’ai appuy sur Ctrl-C aussi vite que possible.
Il s’avre qu’une bonne partie de mon rpertoire personnel a t supprime. Heureusement, il semble que cela ait commenc par les fichiers de configuration et non par les donnes proprement dites, mais je ne suis toujours pas sr d’avoir perdu quoi que ce soit d’important. J’ai teint la machine pour rcuprer les donnes plus tard avec extundelete (a n’a pas march, a plante instantanment pour une raison ou une autre ; j’ai des sauvegardes, mais elles sont un peu dpasses, 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 gre galement la cration automatique de rpertoires de donnes tels que /home, et l’option –purge est destine 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 problme, 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 mme chose – nettoyer les fichiers temporaires, bien que –purge semble « plus complet » car il mentionne qu’il supprime tous les fichiers (y compris les donnes de l’utilisateur).
Cela nous ramne en quelque sorte la section Comportement attendu que vous n’avez pas vu , mais parfois la forme rigide des modles de questions ne s’adapte pas tout – donc, ce que je voudrais voir est :
1. Une explication de la raison pour laquelle une option donne fait quelque chose, par exemple :
–cleanNettoie les fichiers temporaires. [Une explication plus dtaille suit…]
–removeNettoie les fichiers temporaires qui [Je ne sais pas quelle est la diffrence avec –clean, mais expliquez-la]. […]
–purgeSupprime toutes les donnes de l’utilisateur. […]
En tant qu’utilisateur, je ne sais pas quoi ils sont destins, mais en tant que dveloppeurs, vous le savez probablement, et pouvez les dcrire mieux que je ne l’ai fait 
Je ne pense pas que cela soit spcifique systemd-tmpfiles, cela devrait probablement tre utilis comme une ligne directrice sur la faon d’crire des manuels l’chelle du projet (et honntement, l’chelle de l’industrie).
2. Un norme avertissement ct de –purge. Cette option est dangereuse, il faut donc l’indiquer clairement. hdparm(8) en est un bon exemple :
–dco-restoreRinitialise tous les paramtres, caractristiques et capacits accessibles du lecteur aux valeurs par dfaut d’usine et aux capacits totales. Cette commande chouera si DCO est gel/verrouill, ou si une restriction de taille maximale -Np a galement t dfinie. Cette situation est EXTRMEMENT DANGEREUSE et entranera trs probablement une perte massive de donnes. N’UTILISEZ PAS CETTE COMMANDE.
–drq-hsm-errorTRS DANGEREUX, NE PENSEZ MME PAS L’UTILISER. Cette option permet hdparm d’envoyer une commande IDENTIFY au noyau, mais elle est incorrectement marque comme une commande « non-data ». Il en rsulte que la ligne DataReQust(DRQ) du lecteur est « bloque » un niveau lev. Cela perturbe les pilotes du noyau et peut provoquer un crash immdiat du systme avec une perte massive de donnes. L’option existe pour aider tester et renforcer le noyau contre des dysfonctionnements de disques similaires dans le monde rel. TRS DANGEREUX, NE PAS UTILISER !
Pour moi, ce serait suffisant, car je vrifie les options que j’utilise dans le manuel. Je ne suis pas sr qu’il faille une confirmation ou autre, je ne pense pas que ce soit ncessaire, mme si vous avez une confirmation, certaines personnes confirmeront aveuglment de toute faon. 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, dveloppeur de systemd chez Microsoft
Envoy par Luca BoccassiPeut-tre qu’il ne faut pas lancer au hasard des commandes dont vous ne savez rien, tout en ignorant ce que la documentation vous dit ? C’est juste une ide, hein
Mais l’quipe se ravise et apporte une mise jour
En dpit d’une rponse initialement plutt hostile selon laquelle la commande ne faisait que ce qui tait indiqu sur la bote, qu’il fallait toujours lire l’tiquette etc, cette commande a maintenant donn lieu quelques avertissements supplmentaires.
En effet, aprs de nombreuses discussions qui ont dur des jours, le comportement de systemd-tmpfiles a t amlior. Ce patch a t fusionn et permet systemd-tmpfiles d’accepter un fichier de configuration lors de l’excution de purge. De cette faon, l’utilisateur doit fournir en connaissance de cause le(s) fichier(s) de configuration duquel (desquels) il souhaite que les fichiers soient supprims. La documentation a galement t amliore pour rendre le comportement plus clair.
Ce correctif a t intgr dans la version point de systemd 256.1.
En clair, dsormais, la sous-commande –purge insiste sur un fichier de spcification, le rsum 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 dj a. Cela fait partie d’autres changements modestes, bien sr.
C’est un rappel utile toutes les personnes concernes. tant tous trs occups, 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 rfrence une dfinition dsormais obsolte.
Conclusion
Cette situation soulve des questions plus larges sur la transparence des logiciels open source. Les utilisateurs doivent-ils sattendre ce que des commandes apparemment inoffensives puissent avoir des consquences dsastreuses ? Les dveloppeurs doivent-ils tre plus prudents lorsquils conoivent des outils systme ?
La version 256.1 de Systemd a corrig le problme de suppression inattendue du rpertoire /home par systemd-tmpfiles. Cependant, cette controverse nous rappelle limportance de la vigilance et de la communication entre les dveloppeurs et les utilisateurs. Esprons que cette exprience conduira des pratiques plus sres et une meilleure comprhension des risques potentiels dans le monde des logiciels open source.
Sources : GitHub, systemd v256.1
Et vous ?
Pensez-vous que la suppression inattendue du rpertoire /home par systemd-tmpfiles est un problme srieux ? Avez-vous dj rencontr ce problme ou connaissez-vous quelquun qui la vcu ?
Quelles mesures pensez-vous que les dveloppeurs de systemd auraient d prendre pour viter ce problme ? voquez les solutions possibles et partagez vos ides ?
Est-ce que cette vulnrabilit affecte votre utilisation quotidienne de systemd ? Avez-vous / allez-vous modifier votre comportement suite cette dcouverte ?
Pensez-vous que les logiciels open source devraient tre plus transparents concernant les risques potentiels ? Explorez la question de la responsabilit des dveloppeurs et de la communication avec les utilisateurs.
Quelles autres fonctionnalits ou comportements de systemd mritent dtre discuts ? largissez la discussion au-del de ce cas spcifique.