Come mandare in crash systemd

Inutile dirlo, la logica di funzionamento di systemd, che piaccia o meno, può essere comoda per diversi aspetti. La sua ampia integrazione con tutto il sistema Linux porta dei vantaggi, a scapito della semplicità e -ed è proprio il caso di dirlo- della robustezza data dall'avere piccoli software estremamente specializzati ed ottimizzati.

Proprio per questo motivo, systemd ha sempre sofferto di alcune lacune lato sicurezza; l'ultima portata all'attenzione degli utenti, anche se risulta introdotta in un commit risalente a più di 2 anni fa, affligge il sistema di notifica inter-processo di systemd:

NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""

Questo semplice comando, lanciato da qualisiasi utente del sistema, fa si che il PID 1, ovvero quello che si occupa di gestire il sistema di init, si blocchi nella chiamata di sistema pause(). Gli effetti, all'atto pratico, sono i seguenti:

• Non sarà più possibile avviare e fermare i demoni
• I servizi inetd non accetteranno più connessioni
• Non sarà più possibile effettuare un riavvio "pulito" del sistema
• In generale, l'intero sistema diventerà instabile (ad esempio ssh e su rimangono in attesa fino a 30 secondi)

Nonostante alcuni utenti affermano di poterlo riprodurre solo inserendo il comando all'interno di un ciclo while true, molti ne hanno sempre evidenza.

Nonostante i blocchi del PID 1 non siano così rari, negli ultimi anni problemi di questo tipo affliggono sempre più spesso il nuovo sistema di init integrato e, probabilmente, la casistica è così elevata poichè systemd stesso è così tanto complesso ed introduce così tanti elementi esterni e -normalmente- non necessariamente legati al processo di init, che bug in un progetto di tali dimensioni sono decisamente più comuni.

Un'analisi -critica- più approfondita può essere letta a questo link.

Leggi il contenuto originale su Mia mamma usa Linux!