Tra i developer del gestore di sistema systemd è in corso un dibattito sulla riduzione delle dipendenze della libreria libsystemd, che è collegata non solo ai componenti di systemd, ma anche a molte applicazioni esterne. Ad esempio, in Fedora più di 150 pacchetti utilizzano libsystemd come dipendenza. L'iniziatore della discussione ritiene che l'inclusione di ulteriori librerie esterne in libsystemd, che non sono controllate dai developer di systemd, aumenti notevolmente la superficie di attacco in caso di compromissione delle librerie esterne, come è accaduto con la libreria liblzma.
Oltre a liblzma e glibc, in libsystemd vengono anche caricate le librerie libzstd, liblz4 e libgcrypt, e mantenere la sicurezza di queste diventa un compito critico. In libsystemd viene fornito accesso a 12 API di base (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd-path e sd-resolve) e si verifica una situazione in cui un'applicazione, ad esempio, che utilizza libsystemd solo per chiamare la funzione sd_notify per informare systemd di un cambiamento di stato o sd_journal per registrare dati nel log, viene collegata a tutte le altre librerie e gestori dell'API. Come soluzione si propone di dividere libsystemd in diverse librerie separate, ciascuna responsabile di API distinte, consentendo di caricare le dipendenze esterne solo dove sono necessarie.
I developer di systemd ritengono che la divisione non sia fattibile, poiché i gestori presenti in libsystemd sono interconnessi. La separazione richiederebbe un enorme lavoro e porterebbe o a una perdita di efficienza o alla necessità di duplicare il codice. Per ridurre la memoria occupata in libsystemd, di recente è stata adottata una modifica con l'implementazione del caricamento dinamico delle librerie liblzma, libzstd e liblz4 tramite la chiamata dlopen(), nelle situazioni in cui le loro funzioni sono realmente necessarie. Una modifica simile sarà implementata anche per libgcrypt a partire dalla prossima versione.
Tale soluzione è stata oggetto di critiche, poiché invece di un collegamento esplicito e visibile, il caricamento delle librerie esterne avverrà ora in modo implicito, complicando la diagnosi, poiché non è evidente il collegamento tra le chiamate API di libsystemd e le chiamate di funzioni da librerie esterne. Il passaggio a un caricamento tramite dlopen() non cambia l'architettura, ma nasconde semplicemente i componenti esterni a chi gestisce e agli utenti.
Leonard Potttering ha espresso un categorico disaccordo sull'idea di dividere libsystemd in diverse librerie, in quanto tale passo complicerebbe notevolmente la condivisione del codice in systemd e richiederebbe di trasferire tutti i gestori interni a livello pubblico o di compilarli staticamente in ogni libreria. Nel primo caso sorgerebbero problemi nel mantenere la stabilità dell'API e degli spazi dei nomi, mentre nel secondo — un aumento delle dimensioni a causa della duplicazione del codice.
Il caricamento di librerie esterne solo all'occorrenza, implementato per il prossimo rilascio, è percepito da Leonard come una strategia ottimale. Si propone di risolvere il problema della complessità nel reperire informazioni su librerie caricate dinamicamente attraverso l'aggiunta di campi aggiuntivi nei file ELF con informazioni su tali dipendenze dinamiche, che possono essere gestite dai debugger e visualizzate nell'output dello strumento readelf.
Per quanto riguarda il collegamento di un gran numero di applicazioni a libsystemd, Leonard ha consigliato agli sviluppatori di non tentare di caricare libsystemd per una sola funzione, ma di implementare un gestore del protocollo a livello dell'applicazione. Ad esempio, l'implementazione della funzionalità sd_notify() è relativamente banale e può essere realizzata in poche righe di codice utilizzando i socket UNIX (AF_UNIX). Tale implementazione isolata di sd_notify è disponibile per OpenSSH dal 2017 ed è stata recentemente accettata nella versione portabile di OpenSSH 9.8, il cui rilascio è previsto per la metà dell'estate.
Fonte: opennet.ru
