Rastrear, salvar e reverter as modificações do sistema de arquivos feitas por um programa no Linux

9

Eu gostaria de poder, quando um programa como um instalador for executado, rastrear a lista das modificações feitas no meu sistema de arquivos para que eu possa revertê-las posteriormente.

Edição: trata-se de um programa não empacotado . Eu uso o apt-get o mais longe que posso.

Idealmente, eu gostaria de poder fazer algo como:

(sudo) catch-modifs some-installer.bin > fsmodifs.patch

E depois:

(sudo) revert-modifs fsmodifs.patch

Existe uma maneira conveniente de fazer isso?

— Ywen
fonte

1

Possivelmente, a maneira mais fácil (?) De fazer isso é inicializar a partir de um LiveUSB com uma "partição de dados persistente". (Ou, para replicar você mesmo o efeito, em uma prisão chroot: monte uma camada rw sobre uma camada ro.) Tire uma foto do sistema de arquivos rw - que deve ser muito fino após uma nova inicialização - e execute o instalador. Todo arquivo que ele altera ou cria estará na partição de sobreposição rw "dados persistentes". Até os arquivos removidos aparecerão como "arquivos de ponto mágicos".

— BRPocock
fonte

Isso parece complicado ... Não é possível apenas criar uma nova partição, montar o antigo RO e montar sobre ele o novo no RW?

— Ywen

Sim, você pode fazer isso também, no modo de usuário único, talvez. Dê uma olhada no unionfs- basicamente, o sistema de arquivos RW aceita todas as gravações, mas o sistema de arquivos RO ainda está visível abaixo dele. Se um arquivo for alterado, ele "migra" para o RW fs; se for excluído, na verdade existe um "arquivo de ponto mágico" no RW fs para "mascará-lo". A configuração unionfspode ser um pouco delicada, é por isso que sugeri o LiveUSB (ele faz essa parte para você, e você tem uma imagem de sistema “limpa” para começar) #

— BRPocock

2

Talvez dê uma olhada no tripwire? O Tripwire é mais passivo que o seu exemplo ativo, mas ainda pode funcionar para você.

http://www.linuxjournal.com/article/8758

O Tripwire é um sistema de detecção de intrusões (IDS), que, constante e automaticamente, mantém seus arquivos e relatórios críticos do sistema sob controle se eles foram destruídos ou modificados por um cracker (ou por engano). Ele permite que o administrador do sistema saiba imediatamente o que foi comprometido e corrija-o.

— Corith Malin
fonte

1

Dê uma olhada no Installwatch:

http://en.wikipedia.org/wiki/Installwatch#Functionality

http://asic-linux.com.mx/~izto/checkinstall/installwatch.html

— qerub
fonte

Você quer dizer "CheckInstall"? Funciona quando não tenho makefiles? No meu caso (Eclim), a instalação foi feita através de um instalador de jar.

Não, quero dizer o Installwatch, que faz parte do CheckInstall.

— qerub

"O Installwatch funciona com todos os programas ELF vinculados dinamicamente, substituindo as chamadas do sistema que causam alterações no sistema de arquivos. Algumas dessas chamadas do sistema estão abertas (2) e desvinculadas (2)." Deve funcionar bem com uma JVM.

— qerub

Sim, mas aparentemente o Installwatch sozinho não é mais mantido por um longo tempo. Além disso, você precisa do CheckInstall para poder reverter os logs do InstallWatch. Eu ainda deveria dar uma olhada. Obrigado.

1

Use LD_PRELOADpara carregar uma biblioteca que intercepta a openfunção de biblioteca e altera o nome do caminho / registra a saída / faz um backup antes de abrir o arquivo.

Dê uma olhada no código fonte para strace.

— Ben Voigt
fonte

Sim, mas como alguém disse, e se o programa estiver vinculado estaticamente?

— Ywen

0

Se o instalador usa algum recurso de empacotamento (por exemplo .deb, para pacotes para Debian / Ubuntu / ..., .rpmpacotes para RedHat / CentOS / ... etc), o instalador do pacote deve saber o que fazer na instalação e remoção. E acredito que você deve usar os sistemas de embalagem existentes , não inventar o seu próprio. (Linux convencionalmente não tem instaladores como o Windows).

Se você realmente deseja acompanhar as alterações nos arquivos feitas por algum processo, pode usar straceou ltracecapturar chamadas do sistema. Você também pode inotificar e instalações relacionadas.

Mas eu não sei como catch-modifse revert-modifsvocê quer.

Eu sugiro não criar um instalador para o seu aplicativo, mas usar o gerenciador de pacotes, portanto, fornecer .deb(e / ou .rpm) pacotes para o seu aplicativo. Eles lidarão com os problemas de dependência melhor do que o seu próprio instalador.

— Basile Starynkevitch
fonte

Sim, eu uso o apt-get o tempo todo. Eu não estava falando sobre meus próprios aplicativos, mas sobre aplicativos não empacotados. Eu nem sempre tenho um deb. Em mãos.

Os aplicativos descompactados mencionados devem documentar quais arquivos eles usam e como devem ser instalados.

^^ E se não o fizerem? Eu sabia que poderia empacotá-las pessoalmente, mas não é simples . Além disso, esses comandos podem ser úteis para testar de maneira mais segura alguns scripts do sistema que você cria.

Concordo que o seu desejo é interessante, mas eu não tenho certeza se ele é facilmente implementável ....

0

A maneira mais fácil de conseguir o que você deseja: instale o aplicativo "não confiável" em uma instância de máquina virtual totalmente nova (estação de trabalho VMWare, Oracle VirtualBox etc.).

Quando você decidir que não deseja mais o aplicativo, exclua a máquina virtual.

Suas outras alternativas - capturar syscalls de acesso a arquivos - provavelmente serão propensas a erros e incompletas. Seja especialmente cuidadoso com qualquer solução que exija vinculação dinâmica para funcionar (como o Installwatch parece fazer). Um instalador pode legitimamente exercer chamadas diretas ao sistema ou ser vinculado estaticamente.

Uau, a máquina virtual é definitivamente um exagero ... Só preciso salvar e fazer backup de alguns arquivos de configuração de uma maneira conveniente.

— Ywen