Debian X Systemd: quem decide o futuro do /var/lock?

No ecossistema do software livre, decisões técnicas nem sempre são consensuais — e, às vezes, precisam de uma intervenção mais formal. Foi exatamente isso que aconteceu recentemente no Debian, uma das distribuições Linux mais respeitadas e influentes do mundo.

O centro da polêmica? Um diretório aparentemente inofensivo: /var/lock .

O Que é /var/lock, afinal?

Historicamente, é o diretório usado por softwares no armazenamento de arquivos de trava (locks), evitando que dois processos concorram por um mesmo recurso — como portas seriais, impressoras ou outros dispositivos compartilhados.

De acordo com o FHS (Filesystem Hierarchy Standard) — um padrão seguido por muitas distribuições, incluindo o Debian —, esse diretório deve ser gravável por usuários que precisam criar essas travas, não apenas pelo root.

A Mudança no systemd

A controvérsia começou com a atualização do systemd para a versão 258. Nessa versão, os desenvolvedores restringiram as permissões do /var/lock, tornando-o acessível apenas para o usuário root.

A intenção do time do systemd foi clara: incentivar o uso de métodos mais modernos de trava, como o flock(2). No entanto, a mudança quebrou a compatibilidade com diversos pacotes Debian ainda dependentes do comportamento tradicional do /var/lock.

Aí entrou o Comitê Técnico do Debian

Diante do impasse, o caso foi levado ao Comitê Técnico do Debian, quem arbitra decisões técnicas quando desenvolvedores não conseguem chegar a um consenso. Após debates acalorados e análise cuidadosa, ele decidiu anular a mudança feita pelos mantenedores do systemd no Debian.

Em outras palavras: o /var/lock deve continuar com permissões mais abertas, permitindo que programas Debian continuem a funcionar normalmente. Assim, a política oficial do Debian (baseada no FHS – Filesystem Hierarchy Standard) exige que aquel ediretório esteja disponível para uso por outros programas, além do root.

O Comitê usou sua autoridade constitucional (seção 6.1.4 da constituição do Debian) para obrigar os mantenedores do systemd a seguir essa decisão — mesmo contra a vontade deles. A decisão não é um retrocesso técnico, mas sim uma medida de transição para garantir estabilidade.

O /var/lock manterá suas permissões tradicionais até que todos os pacotes Debian afetados migrem para alternativas modernas. Quando isso acontecer, o Debian poderá, então, rever sua política e seguir o caminho proposto pelo systemd.

Conclusão

Os desenvolvedores do Systemd não poderiam comunicar que dariam um prazo X para que os pacotes fossem reconstruídos com a alteração propsta. Para mim, a decisão foi para "quebrar o impasse " e fazer o Debian se mexer para a mudança esperada.

Que também deve colaborar para a melhoria da segurança geral da Distro base e as derivadas, que usarão os mesmos pacotes em lançamentos futuros.

3 curtidas

Freedesktop já tinha combinado com a Canonical e a Red Hat, mas havia um Debian no caminho. Aliás a migração do Debian para SystemD foi muito controversa na época. Pelo menos ainda há muitas distribuições que usam outros sistemas de inicialização, mostrando que a diversidade é um grande trunfo do software livre.

3 curtidas

Mais uma vez SystemD causando uma polêmica desnecessária ao se intrometer nos projetos alheios, esse pessoal tem que parar de causar desgaste e transtorno na vida alheia