Відстеження, збереження та відновлення модифікацій файлової системи, зроблених програмою під Linux

9

Мені б хотілося, щоб після запуску такої програми, як інсталятор, відстежувати список модифікацій, внесених у мою файлову систему, щоб я міг їх потім відновити.

EDIT: Це стосується непакетної програми. Я використовую apt-get наскільки я можу.

В ідеалі я б хотів зробити щось на кшталт:

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

І потім:

(sudo) revert-modifs fsmodifs.patch

Чи є зручний спосіб зробити це?

— Ювен
джерело

1

Можливо, найпростіший (?) Спосіб зробити це - завантажувати LiveUSB з "стійким розділом даних". (Або, щоб повторити ефект самостійно, у в'язниці chroot: встановіть шар rw над шаром ro.) Зробіть знімок файлової системи rw - який повинен бути дуже тонким після нового завантаження - тоді запустіть інсталятор. Кожен файл, який він змінює або створює, буде знаходитись на rw-розділі "постійних даних". Навіть вилучені файли будуть виглядати як "чарівні точкові файли".

— BRPocock
джерело

Це виглядає складно ... Чи не можливо просто створити новий розділ, змонтувати старий RO та встановити над ним новий в RW?

— Ювен

Так, можливо, ви можете це зробити і в режимі для одного користувача, можливо. Погляньте - в unionfsосновному файлова система RW приймає всі записи, але під цим файлом все ще видно файлову систему RO. Якщо файл змінено, він "переміщується" до файлу RW; якщо його видалити, насправді на RW fs є "магічний dotfile", щоб "замаскувати" його. Налаштування unionfsможе бути трохи зворушливим, тому я запропонував LiveUSB (це саме ця частина для вас, і у вас є "чисте" зображення системи для початку)

— BRPocock

2

Може, погляньте на тривимір? Tripwire є більш пасивним, ніж ваш активний приклад, але він все одно може працювати для вас.

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

Tripwire - це система виявлення вторгнень (IDS), яка постійно та автоматично зберігає ваші критичні системні файли та звіти під контролем, якщо вони були знищені чи модифіковані зломщиком (або помилково). Це дозволяє системному адміністратору негайно знати, що було порушено, і виправити це.

— Коріт Малін
джерело

1

Погляньте на Installwatch:

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

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

— qerub
джерело

Ви маєте на увазі "CheckInstall"? Це працює, коли у мене немає файлів? У моєму випадку (Eclim) установка була здійснена через встановитель jar.

Ні, я маю на увазі Installwatch, який є частиною CheckInstall.

— qerub

"Installwatch працює з кожною динамічно пов'язаною програмою ELF, переосмислюючи системні виклики, що викликають зміни файлової системи. Деякі з таких системних дзвінків відкриті (2) та від'єднані (2)." Слід добре працювати з JVM.

— qerub

Так, але, мабуть, лише Installwatch вже давно не підтримується. Крім того, вам потрібно CheckInstall, щоб мати можливість відновити журнали InstallWatch. Мені все одно слід було подивитися. Дякую.

1

Використовується LD_PRELOADдля завантаження бібліотеки, яка перехоплює функцію openбібліотеки та змінює ім'я шляху / записує в журнал вихід / робить резервну копію перед відкриттям файлу.

Погляньте на вихідний код для strace.

— Бен Фойт
джерело

Так, але, як хтось сказав, що робити, якщо програма статично пов'язана?

— Івен

0

Якщо інсталятор використовує якесь обладнання для упаковки (тобто для .debпакунків для Debian / Ubuntu / ..., .rpmпакунків для RedHat / CentOS / ... тощо), тоді інсталятор пакета повинен знати, що робити при встановленні та видаленні. І я вважаю, що ви повинні використовувати існуючі системи пакування , а не вигадувати власну. (У Linux звичайно немає інсталяторів, як у Windows).

Якщо ви дійсно хочете слідкувати за змінами файлів, здійсненими в ході якогось процесу, ви можете використовувати straceабо ltraceвловлювати системні дзвінки. Ви також можете ініціювати та пов'язані з цим споруди.

Але я не знаю такого catch-modifs, revert-modifsяк ти хочеш.

Я пропоную не встановлювати інсталятор для вашої програми, а використовувати менеджер пакунків, отже, надавати .deb(та / або .rpm) пакети для вашої програми. Вони вирішать проблеми залежності краще, ніж ваш власний інсталятор.

— Базиль Старинкевич
джерело

Так, я використовую apt-get весь час. Я говорив не про власні програми, а про незапаковані програми. У мене не завжди є .deb під рукою.

Нерозпаковані програми, які ви згадуєте, повинні документувати, які файли вони використовують та як їх слід встановити.

^^ Що робити, якщо вони цього не роблять? Я знав, що можу сам їх упакувати, але це не просто . Плюс такі команди можуть бути корисними для тестування безпечнішого способу створення деяких системних сценаріїв.

Я погоджуюся, що ваше бажання цікаве, але я не впевнений, чи легко його реалізувати ....

0

Найпростіший спосіб досягти того, що ви хочете: встановіть "ненадійний" додаток у абсолютно новий екземпляр віртуальної машини (робоча станція VMWare, Oracle VirtualBox тощо).

Коли ви вирішите, що більше не хочете програми, видаліть віртуальну машину.

Ваші інші альтернативи - пошук системних дзвінків до файлів - ймовірно, будуть схильними до помилок та неповними. Будьте особливо обережні до будь-якого рішення, яке вимагає динамічного зв’язку для роботи (як це робиться Installwatch). Інсталятор може цілком законно здійснювати прямі системні дзвінки або бути статично пов'язаними.

Нічого, віртуальна машина, безумовно, непомітна ... Мені просто потрібно зберегти та створити резервну копію деяких конфігураційних файлів зручним способом.

— Івен