Quando o rpm -V não verifica o md5sums?

Question

Eu tenho um sistema mais antigo (o Fedora Core 6, é um sistema isolado usado para fazer compilações para dispositivos mais antigos). Estou tentando construir uma VM correspondente e percebi uma diferença que não posso explicar.

Ambos os sistemas possuem o pacote glibc-2.5-3, que inclui o arquivo /lib/libc-2.5.so.

A saída rpm -qi glibc corresponde exatamente aos dois sistemas.

Em ambos os sistemas, rpm -Vv diz que tudo está bem ( ........ /lib/libc-2.5.so ).

O md5sum do arquivo nos dois sistemas NÃO CORRESPONDE. (

Quando faço um objdump -x do arquivo nos dois sistemas, recebo DIFERENTES valores de endereço inicial, confirmando que, de fato, os dois arquivos SO são diferentes.

Então, por que rpm -V me diz que o md5sum combina, quando claramente não é? Como é que essas bibliotecas se tornaram diferentes?

    

Answer 1

Essas bibliotecas são provavelmente pré-conectadas. O RPM sabe sobre a pré-preparação.

Este post fala sobre isso.

The “problem” (if you can call it that) is that rpm knows about prelink, and knows how to deal with it. As is succinctly explained in this mailing list email, “rpm when –verify will prelink –verify, which is essentially –undo followed by prelinking again and comparing.” So the reason that rpm doesn’t fail the verification is that it is basically turning off prelink for the file(s) to check, running the verification, then turning prelink back on. This is why rpm won’t report on a MD5SUM change, but AIDE will.

Onde o e-mail vinculado é:

On Fri, Apr 04, 2003 at 04:24:39PM -0500, James Ralston wrote:

On 2003-04-04 at 11:34:35-0500 Jakub Jelinek wrote:

man prelink

I will eventually write more documentation.

         

Uma pergunta ...

         

Se o prelink modificar os binários e bibliotecas reais no local (o que     parece ser o caso da minha leitura da página man), não é isso     essencialmente fazer "rpm --verify" inútil? Cada binário único e     biblioteca modificada pelo prelink falhará nos testes size / md5sum / mtime.

  

     

Não irá falhar. rpm quando --verify irá prelink --verify, que   é essencialmente --undo seguido por prelacing novamente e comparando.

     

Even if --undo is used to revert the prelinking, "rpm --verify" would still fail (unless prelink restored the exact mtimes that were on the files before it started, that is)...

     O

prelink não modifica os tempos de bibliotecas / binários pré-configurados.

     

Jakub

A outra possibilidade, em geral, é que as verificações de verificação individuais possam ser desabilitadas em um nível por arquivo ou por diretório no próprio arquivo de especificações. Portanto, embora não seja verdade neste caso, é totalmente possível que um empacotador possa desabilitar a verificação de soma MD5 para arquivos que são conhecidos por alterar por um motivo ou outro.