{"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\/de\/blog\/news\/tehnicheskij-komitet-utverdil-izmenenie-povedeniya-systemd-v-debian","title":{"rendered":"Der technische Ausschuss hat die \u00c4nderung des Verhaltens von systemd in Debian genehmigt","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Das technische Komitee, das die endg\u00fcltigen Entscheidungen zu umstrittenen technischen Fragen im Debian-Projekt trifft, hat die \u00c4nderung des Pakets mit systemd genehmigt, die das Verhalten beim Arbeiten mit dem Verzeichnis \/var\/lock \u00e4ndert. Der Systemmanager systemd hat ab Version 258 die Schreibberechtigung f\u00fcr das Verzeichnis \/var\/lock nur f\u00fcr Benutzer mit Root-Rechten eingeschr\u00e4nkt, w\u00e4hrend das technische Komitee von Debian die Beibehaltung des alten Verhaltens genehmigte, das das Schreiben in \/var\/lock f\u00fcr alle Benutzer erlaubt. <\/p>\n
Die Regeln des Debian-Projekts schreiben vor, dass das urspr\u00fcngliche Verhalten der Anwendungen (Einstellungen, die im Upstream festgelegt wurden) beim Erstellen von Paketen beibehalten wird. Um spezifische \u00c4nderungen f\u00fcr Debian an Paketen vorzunehmen, die von den Projektregeln abweichen, ist eine spezielle Genehmigung des technischen Komitees erforderlich. <\/p>\n
Im Fall von systemd unterst\u00fctzte das Komitee den Vorschlag, die \u00c4nderung nicht zu \u00fcbernehmen, die die Zugriffsrechte f\u00fcr \/var\/lock zur Verbesserung der Sicherheit \u00e4ndert, da die M\u00f6glichkeit des \u00f6ffentlichen Schreibens in das Verzeichnis \/var\/lock in der FHS-Spezifikation (Filesystem Hierarchy Standard) erw\u00e4hnt wird und notwendig ist, damit einige vorhandene Programme weiterhin funktionieren k\u00f6nnen. Beispielsweise verwenden Anwendungen f\u00fcr die Arbeit mit seriellen Ports wie uucp, minicom, mgetty+sendfax und hylafax das Verzeichnis \/var\/lock, um den Zugriff auf \/dev\/ttyS*-Ger\u00e4te durch das Erstellen von Lock-Dateien zu trennen. <\/p>\n
Die Notwendigkeit, den Zugriff auf das Verzeichnis \/var\/lock einzuschr\u00e4nken, wird von den Entwicklern von systemd als Schutz gegen DoS-Angriffe erkl\u00e4rt. Das Verzeichnis \/var\/lock ist ein symbolischer Link zum Verzeichnis \/run\/lock. Der Abschnitt mit dem Verzeichnis \/run wird normalerweise separat \u00fcber tmpfs gemountet, und die M\u00f6glichkeit einer unkontrollierten Schreiboperation darin kann verwendet werden, um den Abschnitt zu f\u00fcllen und die Erstellung neuer Dateien in der Hierarchie \/run zu blockieren. <\/p>\n
Um solche Angriffe bei unbeschr\u00e4nktem Zugriff zu verhindern, wurde in Debian fr\u00fcher ein Patch verwendet, der \/run\/lock in eine separate kleine tmpfs-Partition einf\u00fcgte. Im letzten Jahr wurde dieser Patch durch das Unit run-lock.mount ersetzt, und diesen Sommer wurde dieses Unit entfernt, wodurch \/run\/lock nun im Verzeichnis \/run zu finden ist. In den Kommentaren zu der Entscheidung des technischen Komitees empfahl der ehemalige Maintainer von systemd, die erw\u00e4hnte \u00c4nderung nicht zu vergessen und zur separaten Einbindung von \/run\/lock zur\u00fcckzukehren, w\u00e4hrend langfristig alle Anwendungen, die an \/run\/lock gebunden sind, auf Sperren \u00fcber den Mechanismus flock umgestellt werden sollten. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"