{"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\/pt\/blog\/news\/tehnicheskij-komitet-utverdil-izmenenie-povedeniya-systemd-v-debian","title":{"rendered":"O comit\u00ea t\u00e9cnico aprovou a altera\u00e7\u00e3o no comportamento do systemd no Debian","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
O comit\u00ea t\u00e9cnico respons\u00e1vel por tomar decis\u00f5es finais sobre quest\u00f5es t\u00e9cnicas controversas no projeto Debian aprovou uma altera\u00e7\u00e3o no pacote do systemd, que muda o comportamento ao trabalhar com o diret\u00f3rio \/var\/lock. O gerenciador de sistema systemd, a partir da vers\u00e3o 258, restringiu a grava\u00e7\u00e3o no diret\u00f3rio \/var\/lock apenas para usu\u00e1rios com permiss\u00f5es de root, enquanto o comit\u00ea t\u00e9cnico do Debian concordou em manter o comportamento anterior, permitindo a grava\u00e7\u00e3o em \/var\/lock para qualquer usu\u00e1rio. <\/p>\n
As regras do projeto Debian prescrevem a preserva\u00e7\u00e3o do comportamento original das aplica\u00e7\u00f5es (configura\u00e7\u00f5es definidas upstream) ao criar pacotes. Para realizar altera\u00e7\u00f5es espec\u00edficas do Debian em pacotes que contornam as regras do projeto, \u00e9 necess\u00e1ria a obten\u00e7\u00e3o de uma permiss\u00e3o especial do comit\u00ea t\u00e9cnico. <\/p>\n
No caso do systemd, o comit\u00ea apoiou a proposta de n\u00e3o seguir a altera\u00e7\u00e3o que modificava as permiss\u00f5es de acesso ao \/var\/lock com o objetivo de aumentar a seguran\u00e7a, pois a capacidade de grava\u00e7\u00e3o p\u00fablica no diret\u00f3rio \/var\/lock \u00e9 mencionada na especifica\u00e7\u00e3o FHS (Filesystem Hierarchy Standard) e \u00e9 necess\u00e1ria para a continuidade do funcionamento de alguns programas existentes. Por exemplo, aplica\u00e7\u00f5es que operam em portas seriais, como uucp, minicom, mgetty+sendfax e hylafax, utilizam o diret\u00f3rio \/var\/lock para gerenciar o acesso a dispositivos \/dev\/ttyS* atrav\u00e9s da cria\u00e7\u00e3o de arquivos de bloqueio. <\/p>\n
A necessidade de limitar o acesso ao diret\u00f3rio \/var\/lock \u00e9 explicada pelos desenvolvedores do systemd como uma prote\u00e7\u00e3o contra ataques DoS. O diret\u00f3rio \/var\/lock \u00e9 um link simb\u00f3lico para o diret\u00f3rio \/run\/lock. A parti\u00e7\u00e3o com o diret\u00f3rio \/run geralmente \u00e9 montada separadamente via tmpfs, e a capacidade de grava\u00e7\u00e3o desenfreada pode ser utilizada para encher a parti\u00e7\u00e3o e bloquear a cria\u00e7\u00e3o de novos arquivos na hierarquia \/run. <\/p>\n
Para evitar a ocorr\u00eancia de tais ataques com acesso irrestrito, anteriormente no Debian, um patch era utilizado para montar \/run\/lock em uma pequena parti\u00e7\u00e3o tmpfs separada. No ano passado, esse patch foi substitu\u00eddo pela unidade run-lock.mount, e neste ver\u00e3o essa unidade foi removida, fazendo com que \/run\/lock estivesse na parti\u00e7\u00e3o \/run. Nos coment\u00e1rios da decis\u00e3o do comit\u00ea t\u00e9cnico, o ex-mantenedor do systemd recomendou que n\u00e3o se esquecessem da altera\u00e7\u00e3o mencionada e voltassem a montar \/run\/lock separadamente, e a longo prazo, transferissem todos os aplicativos que dependem de \/run\/lock para bloqueios utilizando o mecanismo flock. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"