Chciałbym móc, gdy program taki jak instalator jest uruchomiony, śledzić listę zmian wprowadzonych w moim systemie plików, aby móc je później przywrócić.
EDYCJA: Dotyczy to nieopakowanego programu. Używam apt-get tak daleko, jak to możliwe.
Idealnie chciałbym móc zrobić coś takiego:
(sudo) catch-modifs some-installer.bin > fsmodifs.patch
I wtedy:
(sudo) revert-modifs fsmodifs.patch
Czy jest na to wygodny sposób?
Odpowiedzi:
Być może najłatwiejszym (?) Sposobem na to jest uruchomienie LiveUSB za pomocą „trwałej partycji danych”. (Lub, aby samemu odtworzyć efekt, w więzieniu chroot: zamontuj warstwę rw nad warstwą ro.) Zrób migawkę systemu plików rw - który powinien być bardzo cienki po nowym uruchomieniu - a następnie uruchom instalator. Każdy plik, który zmienia lub tworzy, będzie znajdował się na partycji nakładki „trwałe dane”. Nawet usunięte pliki pojawią się jako „magiczne pliki kropkowe”.
unionfs- w zasadzie system plików RW akceptuje wszystkie zapisy, ale system plików RO jest nadal widoczny pod nim. Jeśli plik się zmieni, „migruje” do pliku RW fs; jeśli zostanie usunięty, faktycznie jest „magiczny plik kropkowy” na RW fs, aby go „zamaskować”. Konfiguracja unionfsmoże być trochę drażliwa, dlatego zasugerowałem LiveUSB (robi to za Ciebie, a ty masz „czysty” obraz systemu na początek)
Może rzucisz okiem na tripwire? Tripwire jest bardziej pasywny niż twój aktywny przykład, ale wciąż może działać dla ciebie.
http://www.linuxjournal.com/article/8758
Tripwire to system wykrywania włamań (IDS), który stale i automatycznie utrzymuje kontrolę nad krytycznymi plikami systemowymi i raportami, jeśli zostały zniszczone lub zmodyfikowane przez crackera (lub przez pomyłkę). Pozwala administratorowi systemu natychmiast dowiedzieć się, co zostało naruszone i naprawić.
Spójrz na Installwatch:
http://en.wikipedia.org/wiki/Installwatch#Functionality
http://asic-linux.com.mx/~izto/checkinstall/installwatch.html
Służy LD_PRELOADdo ładowania biblioteki, która przechwytuje funkcję openbiblioteki i zmienia nazwę ścieżki / rejestruje dane wyjściowe / tworzy kopię zapasową przed otwarciem pliku.
Spójrz na kod źródłowy strace.
Jeśli instalator korzysta z jakiegoś narzędzia do pakowania (np. Dla .debpakietów Debian / Ubuntu / ..., .rpmpakietów dla RedHat / CentOS / ... itd.), Wówczas instalator pakietów powinien wiedzieć, co zrobić podczas instalacji i usuwania. Uważam, że powinieneś korzystać z istniejących systemów pakowania , a nie wymyślać własny. (Linux zwykle nie ma instalatorów takich jak Windows).
Jeśli naprawdę chcesz śledzić zmiany plików dokonane przez jakiś proces, możesz użyć stracelub ltraceprzechwycić wywołania systemowe. Możesz także powiadomić i powiązane usługi.
Ale nie wiem o tematyce catch-modifsi revert-modifsjak chcesz.
Sugeruję, aby nie tworzyć instalatora dla twojej aplikacji, ale aby użyć menedżera pakietów, a zatem zapewnić .deb(i / lub .rpm) pakiety dla twojej aplikacji. Poradzą sobie z problemami zależności lepiej niż twój własny instalator.
Prosty sposób na osiągnięcie tego, co chcesz: zainstaluj „niezaufaną” aplikację w zupełnie nowej instancji maszyny wirtualnej (stacja robocza VMWare, Oracle VirtualBox itp.).
Jeśli zdecydujesz, że nie chcesz już aplikacji, usuń maszynę wirtualną.
Inne alternatywy - przechwytywanie wywołań dostępu do plików - prawdopodobnie będą podatne na błędy i niekompletne. Zachowaj szczególną ostrożność w przypadku każdego rozwiązania wymagającego dynamicznego łączenia w celu działania (jak wydaje się to robić w przypadku Installwatch). Instalator może całkiem legalnie wykonywać bezpośrednie wywołania systemowe lub być statycznie powiązany.