• [^] # Re: En parlant de faille concernant une bibliothèque partagée...

    Posté par . En réponse au journal Faille de sécurité glibc. Évalué à 2.

    j'ai même envie de dire qu'un reboot est obligatoire car le moindre petit programme de rien du tout fait appel à la libc, ce qui fait que celle-ci reste chargée en mémoire (shared lib) tant qu'on l'utilise.

    Les symboles exportés restent donc ceux de l'ancienne shared lib.

    D'ailleurs, avec quelle commande sait-on sous Linux pour afficher les programmes utilisant un shared lib ?

    Sur un os de professionnel comme AIX ça se fait avec la commande "genld -l".
    Ca donne ce genre de sortie :

    Proc_pid: 3932522 Proc_name: ksh93
    100000000 1a7b86 ksh93
    9fffffff0000000 fa8e /usr/ccs/bin/usla64
    90000000046f980 e9bd /usr/lib/libi18n.a[shr_64.o]
    90000000cc0c000 6558c5 /usr/lib/nls/loc/EN_US.UTF-8__64
    900000000461400 b43 /usr/lib/libcrypt.a[shr_64.o]
    90000000047f780 3013b /usr/lib/libiconv.a[shr4_64.o]
    900000000000000 43b3bf /usr/lib/libc.a[shr_64.o]

    Quand on met à jour une shared lib moins cruciale que la libc, on peut vérifier assez rapidement que plus personne ne l'utilise.

    Une fois cette vérification effectuée, on utilise la commande "slibclean" pour forcer le déchargement de la shared lib. On peut ensuite relancer les programme nécessitant la shared lib mise à jour, on est enfin sûr que tous les programmes se servent de la nouvelle version.

    comment faire de même avec Linux ? J'ai cru comprendre qu'il fallait forcer le commit du cache fichier avec un :

    $ echo 3 > /proc/sys/vm/drop_caches

    Mais en résumé, c'est toujours frustrant de devoir rebooter un Unix à cause d'un composant de haut niveau....