{"id":145102,"date":"2025-10-14T17:12:00","date_gmt":"2025-10-14T15:12:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/tehnicheskij-komitet-utverdil-izmenenie-povedeniya-systemd-v-debian"},"modified":"2025-10-14T17:12:00","modified_gmt":"2025-10-14T15:12:00","slug":"tehnicheskij-komitet-utverdil-izmenenie-povedeniya-systemd-v-debian","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/tehnicheskij-komitet-utverdil-izmenenie-povedeniya-systemd-v-debian","title":{"rendered":"Le comit\u00e9 technique a valid\u00e9 le changement de comportement de systemd dans Debian.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Le comit\u00e9 technique, qui prend les d\u00e9cisions finales concernant les questions techniques controvers\u00e9es dans le projet Debian, a approuv\u00e9 une modification du paquet systemd, changeant le comportement du r\u00e9pertoire \/var\/lock. Le gestionnaire de syst\u00e8mes systemd, \u00e0 partir de la version 258, a restreint la possibilit\u00e9 d'\u00e9criture dans le r\u00e9pertoire \/var\/lock uniquement aux utilisateurs ayant des droits root, tandis que le comit\u00e9 technique de Debian a approuv\u00e9 le maintien de l'ancien comportement, permettant l'\u00e9criture dans \/var\/lock \u00e0 tous les utilisateurs. <\/p>\n
Les r\u00e8gles du projet Debian stipulent que le comportement d'origine des applications (param\u00e8tres d\u00e9finis en amont) doit \u00eatre conserv\u00e9 lors de la cr\u00e9ation des paquets. Pour introduire des modifications sp\u00e9cifiques \u00e0 Debian dans les paquets, en contournant les r\u00e8gles du projet, une autorisation sp\u00e9ciale du comit\u00e9 technique est requise. <\/p>\n
Dans le cas de systemd, le comit\u00e9 a soutenu la proposition de ne pas suivre le changement modifiant les droits d'acc\u00e8s \u00e0 \/var\/lock dans le but de renforcer la s\u00e9curit\u00e9, car la possibilit\u00e9 d'\u00e9criture publique dans le r\u00e9pertoire \/var\/lock est mentionn\u00e9e dans la sp\u00e9cification FHS (Filesystem Hierarchy Standard) et est n\u00e9cessaire au fonctionnement de certains programmes existants. Par exemple, des applications fonctionnant avec des ports s\u00e9rie, telles que uucp, minicom, mgetty+sendfax et hylafax, utilisent le r\u00e9pertoire \/var\/lock pour s\u00e9parer l'acc\u00e8s aux appareils \/dev\/ttyS* en cr\u00e9ant des fichiers de verrouillage. <\/p>\n
La n\u00e9cessit\u00e9 de restreindre l'acc\u00e8s au r\u00e9pertoire \/var\/lock est expliqu\u00e9e par les d\u00e9veloppeurs de systemd comme une protection contre les attaques DoS. Le r\u00e9pertoire \/var\/lock est un lien symbolique vers le r\u00e9pertoire \/run\/lock. La partition contenant le r\u00e9pertoire \/run est g\u00e9n\u00e9ralement mont\u00e9e s\u00e9par\u00e9ment via tmpfs, et la possibilit\u00e9 d'\u00e9criture incontr\u00f4l\u00e9e peut \u00eatre utilis\u00e9e pour saturer la partition et bloquer la cr\u00e9ation de nouveaux fichiers dans la hi\u00e9rarchie \/run. <\/p>\n
Pour \u00e9viter la r\u00e9alisation de telles attaques avec un acc\u00e8s illimit\u00e9, un patch \u00e9tait auparavant utilis\u00e9 dans Debian pour monter \/run\/lock dans une petite partition tmpfs distincte. L'ann\u00e9e derni\u00e8re, ce patch a \u00e9t\u00e9 remplac\u00e9 par l'unit\u00e9 run-lock.mount, et cet \u00e9t\u00e9, cette unit\u00e9 a \u00e9t\u00e9 supprim\u00e9e, apr\u00e8s quoi \/run\/lock s'est retrouv\u00e9 dans la partition \/run. Dans les commentaires de la d\u00e9cision du comit\u00e9 technique, l'ancien mainteneur de systemd a recommand\u00e9 de ne pas oublier ce changement signal\u00e9 et de revenir \u00e0 un montage s\u00e9par\u00e9 de \/run\/lock, et \u00e0 long terme, de faire migrer toutes les applications d\u00e9pendant de \/run\/lock vers des verrouillages \u00e0 l'aide du m\u00e9canisme flock. \n Source : opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"