Era da qualche tempo che non parlavamo di Systemd, l’amato e odiato sistema di init dell’ormai stragrande maggioranza delle distribuzioni Linux. Torniamo a farlo in virtù dell’uscita dell’ultima release, la v258.1, che tra le novità ha introdotto una variazione che, come ha raccontato Linuxiac, ha richiesto l’intervento del Debian Technical Committee (DTC).

Il DTC è un gruppo che all’interno del progetto Debian agisce come last resort, quando cioè c’è disaccordo in merito a una strada tecnologica da intraprendere. In questo caso l’intervento si è reso necessario poiché l’ultima citata release di Systemd rende il path /var/lock, che all’interno del Filesystem Hierarchy Standard di Linux è destinato a tutti i file di lock delle varie applicazioni di sistema, scrivibile unicamente dall’utente root.

L’intera storia è iniziata lo scorso 15 settembre, dopo che un utente ha pubblicato il bug report dal titolo “advice for using /var/lock (which is a link to /run/lock) (#1110981)” nel quale segnalava l’impossibilità di scrivere nel path relativo ai lock, che faceva riferimento ad un altro precedente bug che segnalava la questione ed era stato chiuso con lo stato “wontfix“, che in italiano significa “attaccati“.

La decisione si è dipanata su diverse settimane, con prese di posizione che inizialmente non hanno portato ad una soluzione condivisa, ed è stato allora che il DTC è intervenuto, producendo il messaggio incluso nella patch che risolve il problema contenente il seguente messaggio:

The TC therefore resolves that systemd shall provide /var/lock with relaxed enough permissions that existing Debian software that uses /var/lock for system-wide locks of serial devices (and similar purposes) works again. The TC exercises its power under constitution #6.1.4 to overrule the systemd maintainers in this regard.

Il TC quindi conclude che systemd fornirà /var/lock con autorizzazioni abbastanza rilassate che il software Debian esistente che utilizza /var/lock per i blocchi a livello di sistema dei dispositivi seriali (e scopi simili) funzioni di nuovo. Il TC esercita il suo potere in base alla costituzione #6.1.4 per annullare i maintainer di systemd in questo senso.

La specifica imposta ai maintainer systemd, la #6.1.4, si riferisce alla costituzione del progetto Debian che recita nella sezione Poteri (6.1) come, testualmente:

La Commissione Tecnica può chiedere a uno Sviluppatore di intraprendere una particolare serie di azioni tecniche anche se lo Sviluppatore non lo desidera; questo richiede una maggioranza di 3:1. Per Esempio, la Commissione può determinare che una lamentela fatta da chi segnala un baco è giustificata e che la soluzione proposta debba essere implementata.

La semplice linea che ripristina i permessi è questa:

d /run/lock    1777 root root -   -

Nota importante per i poco avvezzi: nonostante lì si veda il numero Linux del diavolo – ossia 777 – che comporta lettura e scrittura da parte di proprietario, gruppo e tutti gli altri (da evitare, sempre e comunque), l’1 anteposto nel settaggio fa sì che la directory in questione sia sì scrivibile da chiunque, ma solo i proprietari dei file hanno il permesso di cancellarli, esattamente come succede per la directory /tmp.

La variazione in questione dovrà quindi essere considerata dai maintainer finché tutte le applicazioni affette (sono parecchie) non verranno migrate ad altri sistemi di gestione dei lock, ad esempio flock.

Intanto però systemd si adeguerà, e non è una sensazione spiacevole.