{"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\/novosti-interneta\/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 gli sviluppatori del gestore di sistema systemd c'\u00e8 un dibattito riguardo alla 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 oltre 150 pacchetti utilizzano libsystemd come dipendenza. L'iniziatore del dibattito sostiene che l'inclusione di ulteriori librerie di terze parti in libsystemd, che non sono controllate dagli sviluppatori di systemd, aumenta notevolmente la superficie di attacco in caso di compromissione delle librerie di terze parti, come accaduto con la libreria liblzma. <\/p>\n
Oltre a liblzma e glibc, in libsystemd vengono caricate anche le librerie libzstd, liblz4 e libgcrypt, la cui sicurezza diventa una priorit\u00e0 critica. Libsystemd fornisce accesso a 12 API fondamentali (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 del cambiamento di stato o sd_journal per registrare dati nel log, si collega a tutte le altre librerie e gestori API. Come soluzione, si propone di suddividere libsystemd in diverse librerie separate, responsabili di singole API, consentendo il caricamento delle dipendenze di terze parti solo dove necessario. <\/p>\n
Gli sviluppatori di systemd ritengono che la suddivisione non sia opportuna, poich\u00e9 gli handler presenti in libsystemd sono interconnessi. La separazione richiederebbe un enorme lavoro e porterebbe o a una perdita di efficienza, oppure alla necessit\u00e0 di duplicare codice. Recentemente, per ridurre l'uso della memoria in libsystemd, \u00e8 stata introdotta 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 effettivamente necessarie. Una modifica simile sar\u00e0 implementata anche per libgcrypt a partire dal prossimo rilascio. <\/p>\n
Tale soluzione ha suscitato critiche, poich\u00e9 invece di un'associazione esplicita e evidente, il caricamento delle librerie esterne avverr\u00e0 in modo non esplicito, complicando la diagnostica, poich\u00e9 non \u00e8 chiara la connessione tra le chiamate API di libsystemd e le funzioni delle librerie esterne. Il passaggio stesso al caricamento tramite dlopen() non cambia l'architettura, ma nasconde soltanto i componenti esterni agli sviluppatori e agli utenti. <\/p>\n
Lenart Pottering ha espresso un forte disaccordo riguardo l'idea di suddividere libsystemd in diverse librerie, poich\u00e9 tale passo complicerebbe notevolmente la condivisione del codice in systemd e richiederebbe di rendere tutti i gestori interni pubblici o di compilarli staticamente in ciascuna libreria. Nel primo caso si verificherebbero problemi nel mantenimento della stabilit\u00e0 dell'API e degli spazi dei nomi, mentre nel secondo si registrerebbe un aumento delle dimensioni a causa della duplicazione del codice. <\/p>\n
La strategia di caricare librerie esterne solo quando necessario, implementata per la prossima versione, \u00e8 considerata da Lenart come l'approccio ottimale. Si propone di risolvere il problema della complessit\u00e0 nel reperire dati sulle librerie caricate dinamicamente aggiungendo nei file ELF campi aggiuntivi con informazioni su tali dipendenze dinamiche, che possono essere elaborate dai debugger e visualizzate nell'output dello strumento readelf. <\/p>\n
Per quanto riguarda il collegamento di un gran numero di applicazioni a libsystemd, Lenart ha raccomandato agli sviluppatori di applicazioni di non cercare di caricare libsystemd per una sola funzione, ma di implementare un gestore del protocollo a livello di applicazione. Ad esempio, l'implementazione della funzionalit\u00e0 sd_notify() \u00e8 abbastanza semplice e pu\u00f2 essere realizzata in poche righe di codice utilizzando i socket UNIX (AF_UNIX). Una 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 met\u00e0 estate. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"