{"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\/it\/blog\/news\/tehnicheskij-komitet-utverdil-izmenenie-povedeniya-systemd-v-debian","title":{"rendered":"Il comitato tecnico ha approvato la modifica del comportamento di systemd in Debian","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Il comitato tecnico, che prende decisioni finali riguardo a questioni tecniche controverse nel progetto Debian, ha approvato la modifica del pacchetto systemd, che cambia il comportamento nella gestione della directory \/var\/lock. A partire dalla versione 258, il gestore di sistema systemd ha limitato la scrittura nella directory \/var\/lock esclusivamente agli utenti con diritti di root, mentre il comitato tecnico di Debian ha approvato il mantenimento del vecchio comportamento, che consente la scrittura in \/var\/lock a qualsiasi utente. <\/p>\n
Le regole del progetto Debian prevedono il mantenimento del comportamento originale delle applicazioni (impostazioni fornite in upstream) durante la creazione dei pacchetti. Per apportare modifiche specifiche per Debian ai pacchetti, eludendo le regole del progetto, \u00e8 necessario ottenere una speciale autorizzazione dal comitato tecnico. <\/p>\n
Nel caso di systemd, il comitato ha sostenuto la proposta di non seguire la modifica che cambia i diritti di accesso a \/var\/lock al fine di aumentare la sicurezza, poich\u00e9 la possibilit\u00e0 di scrittura pubblica nella directory \/var\/lock \u00e8 menzionata nella specifica FHS (Filesystem Hierarchy Standard) ed \u00e8 necessaria per continuare a far funzionare alcuni programmi esistenti. Ad esempio, le applicazioni per la gestione di porte seriali, come uucp, minicom, mgetty+sendfax e hylafax, utilizzano la directory \/var\/lock per dividere l'accesso ai dispositivi \/dev\/ttyS* attraverso la creazione di file di blocco. <\/p>\n
La necessit\u00e0 di limitare l'accesso alla directory \/var\/lock \u00e8 spiegata dagli sviluppatori di systemd come una protezione contro gli attacchi DoS. La directory \/var\/lock \u00e8 un collegamento simbolico alla directory \/run\/lock. La partizione con la directory \/run viene solitamente montata separatamente tramite tmpfs e la possibilit\u00e0 di scrittura incontrollata pu\u00f2 essere utilizzata per saturare la partizione e impedire la creazione di nuovi file nella gerarchia \/run. <\/p>\n
Per prevenire attacchi simili in presenza di accesso illimitato, in precedenza in Debian \u00e8 stata utilizzata una patch che montava \/run\/lock in una piccola partizione tmpfs separata. Lo scorso anno, questa patch \u00e8 stata sostituita dall'unit\u00e0 run-lock.mount, e quest'estate quest'unit\u00e0 \u00e8 stata rimossa, dopo di che \/run\/lock si \u00e8 trovato nella partizione \/run. Nei commenti alla decisione del comitato tecnico, l'ex manutentore di systemd ha raccomandato di non dimenticare la modifica menzionata e di tornare a un montaggio separato di \/run\/lock, e a lungo termine di migrare tutte le applicazioni legate a \/run\/lock su blocchi utilizzando il meccanismo flock. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"