{"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\/es\/blog\/news\/tehnicheskij-komitet-utverdil-izmenenie-povedeniya-systemd-v-debian","title":{"rendered":"El comit\u00e9 t\u00e9cnico ha aprobado un cambio en el comportamiento de systemd en Debian","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
El comit\u00e9 t\u00e9cnico que toma decisiones finales sobre temas t\u00e9cnicos controvertidos en el proyecto Debian ha aprobado un cambio en el paquete de systemd que modifica el comportamiento en relaci\u00f3n con el directorio \/var\/lock. A partir de la versi\u00f3n 258, el gestor de sistemas systemd ha limitado la capacidad de escritura en el directorio \/var\/lock \u00fanicamente a los usuarios con privilegios de root, mientras que el comit\u00e9 t\u00e9cnico de Debian ha aprobado mantener el comportamiento anterior que permite la escritura en \/var\/lock a cualquier usuario. <\/p>\n
Las reglas del proyecto Debian estipulan que se debe conservar el comportamiento original de las aplicaciones (configuraciones establecidas en upstream) al crear paquetes. Para realizar cambios espec\u00edficos de Debian en los paquetes que van en contra de las reglas del proyecto, se necesita obtener un permiso especial del comit\u00e9 t\u00e9cnico. <\/p>\n
En el caso de systemd, el comit\u00e9 apoy\u00f3 la propuesta de no seguir el cambio que altera los permisos de acceso a \/var\/lock con el objetivo de aumentar la seguridad, ya que la posibilidad de escritura p\u00fablica en el directorio \/var\/lock se menciona en la especificaci\u00f3n FHS (Filesystem Hierarchy Standard) y es necesaria para el funcionamiento continuo de algunos programas existentes. Por ejemplo, aplicaciones que trabajan en puertos serie, como uucp, minicom, mgetty+sendfax y hylafax, utilizan el directorio \/var\/lock para gestionar el acceso a los dispositivos \/dev\/ttyS* mediante la creaci\u00f3n de archivos de bloqueo. <\/p>\n
La necesidad de restringir el acceso al directorio \/var\/lock es explicada por los desarrolladores de systemd como una protecci\u00f3n contra ataques de DoS. El directorio \/var\/lock es un enlace simb\u00f3lico al directorio \/run\/lock. La secci\u00f3n con el directorio \/run generalmente se monta por separado mediante tmpfs, y la posibilidad de escritura incontrolada en \u00e9l puede utilizarse para llenar la secci\u00f3n y bloquear la creaci\u00f3n de nuevos archivos en la jerarqu\u00eda \/run. <\/p>\n
Para evitar ataques similares con acceso ilimitado, anteriormente se utilizaba un parche en Debian que montaba \/run\/lock en una peque\u00f1a partici\u00f3n tmpfs. El a\u00f1o pasado, este parche fue reemplazado por el m\u00f3dulo run-lock.mount, y este verano, dicho m\u00f3dulo fue eliminado, despu\u00e9s de lo cual \/run\/lock qued\u00f3 en la partici\u00f3n \/run. En los comentarios de la decisi\u00f3n del comit\u00e9 t\u00e9cnico, el ex mantenedor de systemd recomend\u00f3 no olvidar este cambio y volver a montar \/run\/lock por separado, y a largo plazo, trasladar todas las aplicaciones que dependen de \/run\/lock a bloqueos mediante el mecanismo flock. \n Fuente: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"