{"id":114764,"date":"2024-04-03T12:25:48","date_gmt":"2024-04-03T10:25:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/inicziativa-po-sokrashheniyu-zavisimostej-u-libsystemd"},"modified":"2024-04-03T12:25:48","modified_gmt":"2024-04-03T10:25:48","slug":"inicziativa-po-sokrashheniyu-zavisimostej-u-libsystemd","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/inicziativa-po-sokrashheniyu-zavisimostej-u-libsystemd","title":{"rendered":"Iniziativa per ridurre le dipendenze in libsystemd","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Tra i developer del gestore di sistema systemd \u00e8 in corso un dibattito sulla riduzione delle dipendenze della libreria libsystemd, che \u00e8 collegata non solo ai componenti di systemd, ma anche a molte applicazioni esterne. Ad esempio, in Fedora pi\u00f9 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 \u00e8 accaduto con la libreria liblzma. <\/p>\n
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. <\/p>\n
I developer di systemd ritengono che la divisione non sia fattibile, poich\u00e9 i gestori presenti in libsystemd sono interconnessi. La separazione richiederebbe un enorme lavoro e porterebbe o a una perdita di efficienza o alla necessit\u00e0 di duplicare il codice. Per ridurre la memoria occupata in libsystemd, di recente \u00e8 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\u00e0 implementata anche per libgcrypt a partire dalla prossima versione. <\/p>\n
Tale soluzione \u00e8 stata oggetto di critiche, poich\u00e9 invece di un collegamento esplicito e visibile, il caricamento delle librerie esterne avverr\u00e0 ora in modo implicito, complicando la diagnosi, poich\u00e9 non \u00e8 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. <\/p>\n
Lenart Pottering ha espresso un fermo dissenso riguardo all'idea di suddividere libsystemd in pi\u00f9 librerie, poich\u00e9 un tale passo complicerebbe notevolmente l'uso condiviso del codice in systemd e richiederebbe di convertire tutti i gestori interni in pubblici o di compilarli staticamente in ogni libreria. Nel primo caso, sorgerebbero problemi nel mantenere la stabilit\u00e0 dell'API e degli spazi dei nomi, mentre nel secondo si avrebbe un aumento della dimensione a causa della duplicazione del codice. <\/p>\n
Il caricamento di librerie esterne solo all'occorrenza, implementato per il prossimo rilascio, \u00e8 percepito da Leonard come una strategia ottimale. Si propone di risolvere il problema della complessit\u00e0 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. <\/p>\n
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\u00e0 sd_notify() \u00e8 relativamente banale e pu\u00f2 essere realizzata in poche righe di codice utilizzando i socket UNIX (AF_UNIX). Tale implementazione isolata di sd_notify \u00e8 disponibile per OpenSSH dal 2017 ed \u00e8 stata recentemente accettata nella versione portabile di OpenSSH 9.8, il cui rilascio \u00e8 previsto per la met\u00e0 dell'estate. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"