Discussion :

[Stéphane le calme]

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 :

--cleanNettoie les fichiers temporaires. [Une explication plus détaillée suit...]

--removeNettoie les fichiers temporaires qui [Je ne sais pas quelle est la différence avec --clean, mais expliquez-la]. [...]

--purgeSupprime toutes les données de l'utilisateur. [...]

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 :

--dco-restoreRéinitialise tous les paramètres, caractéristiques et capacités accessibles du lecteur aux valeurs par défaut d'usine et aux capacités totales. Cette commande échouera si DCO est gelé/verrouillé, ou si une restriction de taille maximale -Np a également été définie. Cette situation est EXTRÊMEMENT DANGEREUSE et entraînera très probablement une perte massive de données. N'UTILISEZ PAS CETTE COMMANDE.

--drq-hsm-errorTRÈS DANGEREUX, NE PENSEZ MÊME PAS À L'UTILISER. Cette option permet à hdparm d'envoyer une commande IDENTIFY au noyau, mais elle est incorrectement marquée comme une commande "non-data". Il en résulte que la ligne DataReQust(DRQ) du lecteur est "bloquée" à un niveau élevé. Cela perturbe les pilotes du noyau et peut provoquer un crash immédiat du système avec une perte massive de données. L'option existe pour aider à tester et à renforcer le noyau contre des dysfonctionnements de disques similaires dans le monde réel. TRÈS DANGEREUX, NE PAS UTILISER !

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

Donc une option qui est littéralement documentée comme disant "tous les fichiers et répertoires créés par une entrée tmpfiles.d/ seront supprimés", dont vous ne saviez rien, vous a semblé être une "bonne idée" ? Avez-vous au moins regardé quelles entrées tmpfiles.d vous aviez au préalable ?

Peut-ê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 idée, hein

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.

[TotoParis]

Quand je lis "tmpfiles" dans un nom de commande LINUX, je m'attends à traiter ce qui est dans la branche "tmp@ -> private/tmp", pas "home/" !!! Dans Linux, je ne souviens pas d'avoir vu du "tmp" dans un "home"...Mais c'est le cas sous WINDOWS, où chaque compte utilisateur à un répertoire de ce genre.
Donc la pensée des gens qui ont conçu cette commande est sans doute abîmée par la drogue, l'alcool, le manque de sommeil...

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 ?
Ben non, tout perdre c'est super cool, hein ?

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 ?
Ben un sacré avertissement avec double confirmation et saisie du mot de passe à chaque fois, c'est pas de refus.

Est-ce que cette vulnérabilité affecte votre utilisation quotidienne de systemd ? Avez-vous / allez-vous modifier votre comportement suite à cette découverte ?
Je sous MAC OS, donc je ne suis pas concerné, mais si un jour je passe à LINUX, je serai très vigilant.

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.
Oui, OPEN SOURCE ou pas, les personnes qui mettent à disposition un logiciel, surtout aussi sensible que SYSTEM-D ("D" comme "DEMERDEZ-VOUS" ?) sont juridiquement responsables.

Quelles autres fonctionnalités ou comportements de systemd méritent d’être discutés ? Élargissez la discussion au-delà de ce cas spécifique.
Aucune iD, mais vu toutes les polémiques qui ont accompagné ce logiciel depuis le Début, je vois que c'est encore pire que ce que j'avais lu ici et là...

Sinon, la réponse méprisante de Luca Boccassi montre bien que ce type est bel enculD...