Re: Faille critique découverte dans GLIBC
mrr wrote on Thu, Jan 29, 2015 at 02:17:32PM +0100
> >>Ah, au fait, petite question. Après les commandes ci-dessus,
> >>faut-il que je fasse un reboot ?
>
> J'ajouterais, dans un souci d'échange et de discussion, que le
> reboot ne me semble pas si important que cela (aie, je prend un
> risque en disant cela), pourquoi?
Il faut juste penser à prévenir les utilisateurs suffisamment à
l'avance pour éviter de leur casser la baraque.
Dominique
> Les fichiers qui correspondent aux processus exécutés sur un système
> Linux sont protégés en écriture, petit rappel:
> $ cat >> read_bloquant.c << FIN
>
> # include <stdio.h>
>
> int main (void)
> {
> read (0, NULL, sizeof(int));
>
> /* En gros on exécute un appel système bloquant, on lit depuis
> l'entrée standard, en général la console, NULL parce qu'on s'en fout
> du résultat et le sizeof parce que ça fait plus cool qu'un 4 ou un 8
> (et portable). Donc tant qu'on n'entre pas un caractère (dac, un
> nombre (cela dit, c'est du C, c'est pareil pour "lui", chez moi il
> en mange 4 donc int = 4 octets, moins si caractère en dehors ascii
> et si console en UTF-8 par ex) et qu'on n'appuie pas sur Entrée le
> programme attend */
>
> exit (0);
> }
>
> FIN
>
> Désolé si ça fait un peu cours et pour tout ceux qui savent déjà tout ça!
> Donc on compile et on exécute:
>
> $ gcc read_bloquant.c -o read_bloquant
> $ ./read_bloquant
>
> Ça y est, le processus attend.
> Sur une autre console :
>
> $ kate read_bloquant
> (ou gedit, mousepad etc.)
>
> Impossible de sauvegarder les modifs (on peut avec vim, allez savoir!).
> Et possible lorsque le programme n'est pas exécuté.
>
> Lorsque j'ai mis à jour la libc sur ma wheezy je n'ai pas eu de
> souci particulier, virtualbox (qui n'était pas en exécution) s'est
> recompilé son module, 2-3 petits trucs et c'était bon.
> Ce que j'en conclus, c'est que sur mon système la mise à jour n'a
> remplacé aucun fichier en cours d'utilisation donc que le reboot
> n'est peut-être pas indispensable.
>
>
> Toutefois, juste pour être sûr et si j'étais admin je viderais tout
> ce qui est buffer/cache avant la mise à jour et également après tant
> qu'à faire:
> # echo 3 > /proc/sys/vm/drop_caches
>
> Et si ça swappe (c'est pas dit avec tout ces ordi à 8+ Gb de ram),
> je tuerais quelque processus après avoir exécuté:
> # echo 0 > /proc/sys/vm/swappiness
>
> Attention tout de même à ne pas exécuter cela sur un pc avec très
> peu de mémoire mais de toute façon je suis même pas sûr que cette
> dernière ligne aurait de l'effet dans ce cas.
>
> Une dernière chose:
> Un programme peut être lié à une ABI de la libc de façon statique ou
> dynamique.
>
> Si c'est dynamique comme l'appel à read ci-dessus (on peux voir
> entre autres grâce à strace que c'est
> /lib/i386-linux-gnu/i686/cmov/libc.so.6 qui est appelé chez moi),
> aucun problème tant que le programme utilise un cache bien mis à
> jour (ce qui est normalement le cas mais c'est t'on jamais d'où les
> 2 dernières commandes).
>
> Si c'est statique (avec la libc ce doit être rare voire inexistant,
> j'ai pas vérifié), alors là un reboot n'y fera rien, il faudra
> recompiler le paquet, c'est d'ailleurs un des principaux désavantage
> des librairies statiques (avec la quantité d'espace mémoire
> utilisée, l'avantage étant un programme très légèrement plus
> rapide).
>
> Voilà pour mes petites réflexion, s'il y a des erreurs de logique
> merci de me corriger.
>
> Cordialement/Bises...
>
> --
> mrr
>
> --
> Lisez la FAQ de la liste avant de poser une question :
> http://wiki.debian.org/fr/FrenchLists
>
> Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
> vers debian-user-french-REQUEST@lists.debian.org
> En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
> Archive: [🔎] 54ca32ea$0$3190$426a74cc@news.free.fr">https://lists.debian.org/[🔎] 54ca32ea$0$3190$426a74cc@news.free.fr
>
--
Reply to: