{"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\/novosti-interneta\/tehnicheskij-komitet-utverdil-izmenenie-povedeniya-systemd-v-debian","title":{"rendered":"Das Technische Komitee hat die \u00c4nderung des Verhaltens von systemd in Debian genehmigt.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Das technische Komitee, das endg\u00fcltige Entscheidungen zu umstrittenen technischen Fragen im Debian-Projekt trifft, hat die \u00c4nderung des Pakets mit systemd genehmigt, die das Verhalten im Zusammenhang mit dem Verzeichnis \/var\/lock \u00e4ndert. Der Systemmanager systemd hat ab Version 258 die M\u00f6glichkeit, in das Verzeichnis \/var\/lock zu schreiben, nur auf Benutzer mit root-Rechten beschr\u00e4nkt, w\u00e4hrend das technische Komitee von Debian das alte Verhalten genehmigt hat, 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 von Anwendungen (Einstellungen, die in der upstream-Version eingestellt sind) bei der Paketbildung beibehalten wird. F\u00fcr spezifische \u00c4nderungen in Debian-Paketen, die die Projektregeln umgehen, ist die Genehmigung des technischen Komitees erforderlich. <\/p>\n
Im Fall von systemd unterst\u00fctzte der Ausschuss den Vorschlag, die \u00c4nderung, die die Zugriffsrechte auf \/var\/lock ver\u00e4ndert, um die Sicherheit zu erh\u00f6hen, abzulehnen, da die M\u00f6glichkeit des \u00f6ffentlichen Schreibens in das Verzeichnis \/var\/lock in der Spezifikation FHS (Filesystem Hierarchy Standard) erw\u00e4hnt wird und f\u00fcr den Betrieb bestimmter bestehender Programme erforderlich ist. Beispielsweise verwenden Anwendungen f\u00fcr serielle Ports wie uucp, minicom, mgetty+sendfax und hylafax das Verzeichnis \/var\/lock, um den Zugriff auf die Ger\u00e4te \/dev\/ttyS* durch das Erstellen von Lockfiles zu trennen. <\/p>\n
Die Notwendigkeit, den Zugriff auf das Verzeichnis \/var\/lock einzuschr\u00e4nken, wird von den Entwicklern von systemd als Schutz vor DoS-Angriffen 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 des unkontrollierten Schreibens darin kann genutzt werden, um den Abschnitt zu \u00fcberlaufen und die Erstellung neuer Dateien in der Hierarchie \/run zu blockieren. <\/p>\n
Um Angriffe mit unbeschr\u00e4nktem Zugriff zu verhindern, wurde in Debian fr\u00fcher ein Patch verwendet, der \/run\/lock in einem separaten kleinen tmpfs-Volume mountet. Im letzten Jahr wurde dieser Patch durch das Unit run-lock.mount ersetzt, und diesen Sommer wurde dieses Unit entfernt, wodurch \/run\/lock im Verzeichnis \/run gelandet ist. In den Kommentaren zu dieser Entscheidung empfahl der ehemalige Maintainer von systemd, die vorgenommene \u00c4nderung nicht zu vergessen und zum separaten Mounten von \/run\/lock zur\u00fcckzukehren. Langfristig sollten alle Anwendungen, die auf \/run\/lock angewiesen sind, auf Sperren mit dem Mechanismus flock umgestellt werden. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"