Re: Faille critique découverte dans GLIBC
Le 30/01/2015 01:45, Vincent Lefevre a écrit :
>> Tu parles bien de la mis à jour d'une lib ?
>> Dans ce cas, je ne comprends pas trop ce que tu veux dire par "nouvel inode".
>> Par exemple, j'ai ça :
>>
>> ~$ touch /tmp/foo.so
>> ~$ touch /tmp/foo.so.new-version
>>
>> ~$ ls -i /tmp/foo.so*
>> 523294 /tmp/foo.so 523295 /tmp/foo.so.new-version
>>
>> # Je considère la commande ci-dessous comme une màj du fichier foo.so
>> ~$ cp /tmp/foo.so.new-version /tmp/foo.so
>>
>> # Et je constate que le numéro d'inode de foo.so n'a pas bougé ?
>> ~$ ls -i /tmp/foo.so*
>> 523294 /tmp/foo.so 523295 /tmp/foo.so.new-version
>
> Mais une mise à jour ne fait pas un cp. Un "cp" va modifier un
> fichier si la destination existe, pas créer un nouveau fichier.
Ok et une màj, ça fait quoi alors ? Ça fait globalement ceci ?
rm foo.so && cp /working/dir/de/apt/foo.so /chemin/de/foo.so
Auquel cas effectivement l'inode associé au fichier foo.so
n'est plus le même.
Et donc, si j'ai bien suivi ce qui suit dans tes explications,
l'ancienne version de foo.so n'est plus accessible via
l'arborescence du file system mais l'inode vers l'ancien fichier
foo.so existe toujours dans la table des inodes du fs et donc
la zone de disque où se trouve encore l'ancienne version de
foo.so existe toujours et elle est encore non disponible en
écriture tant qu'il existera des processus qui font référence
à cet inode parce (qu'ils ont ouvert l'ancienne version du fichier
foo.so). Quand tous ces processus seront morts, l'inode pointant
vers l'ancienne versio de foo.so sera supprimé de la table des
inodes et la zone de disque (celle où se trouve l'ancienne version
de foo.so) sera à nouveau disponible (bref l'ancienne version de
foo.so est définitivement perdue).
J'ai bon ?
>> Du coup, j'ai pas dû comprendre quelque chose dans ta phrase.
>>
>>> qui contient la nouvelle version du fichier, mais l'inode
>>> originel reste présent
>>
>> Présent où ça ? Dans les « attributs » des processus en cours ?
>
> Présent sur le disque (et référencé par les processus).
Ok.
>>> tant qu'il reste des liens, donc tant qu'il n'est
>>> pas fermé par les processus qui l'ont ouvert.
>>
>> Mais durant cette période transitoire où il reste encore des
>> processus qui ont ouvert un fichier situé sur une zone A du
>> disque, zone pointée par cet « ancien » inode, qu'en est-il
>> de cette zone A du disque ? Est-elle disponible ou non ?
>
> Non, elle n'est toujours pas disponible. Le fichier existe
> toujours. Cf la page man unlink(2):
>
> unlink() deletes a name from the filesystem. If that name was the last
> link to a file and no processes have the file open, the file is deleted
> and the space it was using is made available for reuse.
>
> If the name was the last link to a file but any processes still have
> the file open, the file will remain in existence until the last file
> descriptor referring to it is closed.
>
> If the name referred to a symbolic link, the link is removed.
Ok, on est d'accord que dans le cas du deuxième paragraphe, le
fichier existe toujours mais il complètement inaccessible via
l'arborescence du file system ? (ce qui est, je trouve, pas commun).
>> Si je comprends bien d'un côté cette zone n'est plus accessible via
>> l'arborescence du filesystem car l'ancien inode n'existe plus. Du
>> coup, cette zone du disque serait libre en quelques sortes ?
>
> Non, l'ancien inode existe toujours (je suppose qu'un processus
> qui a le fichier ouvert peut toujours faire un fstat sur le
> descripteur de fichier pour obtenir le numéro d'inode).
Ok, merci pour ces explications Vincent. :)
--
François Lafont
Reply to: