{"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\/nl\/blog\/news\/tehnicheskij-komitet-utverdil-izmenenie-povedeniya-systemd-v-debian","title":{"rendered":"Het technische comit\u00e9 heeft de verandering van het gedrag van systemd in Debian goedgekeurd.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
De technische commissie die eindbeslissingen neemt over betwiste technische kwesties binnen het Debian-project heeft een wijziging goedgekeurd in het pakket met systemd, die het gedrag van de map \/var\/lock verandert. Het systeembeheerder systemd heeft vanaf release 258 de mogelijkheid om te schrijven naar de map \/var\/lock beperkt tot gebruikers met root-rechten, terwijl de technische commissie van Debian heeft goedgekeurd dat het oude gedrag, dat schrijven naar \/var\/lock voor alle gebruikers toestaat, behouden blijft. <\/p>\n
De regels van het Debian-project schrijven voor dat het originele gedrag van applicaties (instellingen die zijn ingesteld in upstream) moet worden behouden bij het maken van pakketten. Voor wijzigingen die specifiek zijn voor Debian en die de projectregels omzeilen, is een speciale toestemming van de technische commissie vereist. <\/p>\n
In het geval van systemd heeft de commissie het voorstel ondersteund om de wijziging die de toegangsrechten tot \/var\/lock aanpast en die de beveiliging versterkt te negeren, omdat de mogelijkheid van openbare schrijfrechten in de map \/var\/lock wordt vermeld in de FHS-specificatie (Filesystem Hierarchy Standard) en noodzakelijk is voor de voortgang van sommige bestaande programma's. Bijvoorbeeld, applicaties voor het werken met seri\u00eble poorten, zoals uucp, minicom, mgetty+sendfax en hylafax, gebruiken de map \/var\/lock om de toegang tot apparaten \/dev\/ttyS* te scheiden door blokkeringbestanden te cre\u00ebren. <\/p>\n
De noodzaak om de toegang tot de map \/var\/lock te beperken wordt door de ontwikkelaars van systemd verklaard als een bescherming tegen DoS-aanvallen. De map \/var\/lock is een symbolische link naar de map \/run\/lock. Het gedeelte met de map \/run wordt meestal apart gemonteerd via tmpfs en de mogelijkheid van ongecontroleerd schrijven daarin kan worden gebruikt om de sectie te overladen en de creatie van nieuwe bestanden in de hi\u00ebrarchie \/run te blokkeren. <\/p>\n
Om dergelijke aanvallen te voorkomen bij onbeperkte toegang, werd er voorheen in Debian een patch gebruikt die \\\/run\\\/lock monteert in een aparte, kleine tmpfs-partitie. Afgelopen jaar werd deze patch vervangen door de eenheid run-lock.mount, en deze zomer werd deze eenheid verwijderd, waarna \\\/run\\\/lock zich in de partitie \\\/run bevond. In de commentaren bij de beslissing van het technische comit\u00e9 raadde de voormalige maintainer van systemd aan om de aangegeven wijziging niet te vergeten en terug te keren naar de aparte montage van \\\/run\\\/lock, en op de lange termijn alle toepassingen die afhankelijk zijn van \\\/run\\\/lock over te zetten naar lockmechanismen met behulp van flock. \n Bron: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"