9

I'd like to be able to, when a program such as an installer is ran, track the list of the modifications made to my filesystem so that I can revert them afterwards.

EDIT: This concerns a non-packaged program. I use apt-get as far as I can.

Ideally I'd like to be able to do something like:

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

And then:

(sudo) revert-modifs fsmodifs.patch

Is there a convenient way to do that?

Ywen
  • 193
  • 4

6 Answers6

2

Maybe take a look at tripwire? Tripwire is more passive than your active example, but it still may work for you.

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

Tripwire is an intrusion detection system (IDS), which, constantly and automatically, keeps your critical system files and reports under control if they have been destroyed or modified by a cracker (or by mistake). It allows the system administrator to know immediately what was compromised and fix it.

Corith Malin
  • 195
  • 4
1

Take a look at Installwatch:

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

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

qerub
  • 249
  • 2
  • 5
  • You mean "CheckInstall"? Does it work when I don't have makefiles? In my case (Eclim) the installation was made through a jar installer. –  Dec 27 '11 at 13:03
  • No, I mean Installwatch which is a part of CheckInstall. – qerub Dec 27 '11 at 14:40
  • "Installwatch works with every dynamically linked ELF program, overriding system calls that cause file system alterations. Some of such system calls are open(2) and unlink(2)." Should work fine with a JVM. – qerub Dec 27 '11 at 14:40
  • Yes but apparently Installwatch _alone_ has been no longer maintained for a long time. Plus you need CheckInstall to be able to revert InstallWatch logs. I should still have a look. Thanks. –  Dec 27 '11 at 15:28
1

Possibly the easiest (?) way to do this is to boot off of a LiveUSB with a "persistent data partition." (Or, to replicate the effect yourself, in a chroot jail: mount a rw layer over a ro layer.) Take a snapshot of the rw filesystem -- which should be very slim after a fresh boot -- then run your installer. Every file it alters or creates will be on the rw "persistent data" overlay partition. Even removed files will appear as "magic dotfiles."

BRPocock
  • 198
  • 6
  • This looks complicated... Isn't it possible just to create a new partition, mount the old one RO and mount over it the new one in RW? – Ywen Dec 28 '11 at 08:59
  • Yes, you can do that as well, from single-user-mode, perhaps. Take a look at the `unionfs` ­— basically, the RW filesystem accepts all the writes, but the RO filesystem is still visible beneath it. If a file's changed, it “migrates” to the RW fs; if it's deleted, there's actually a “magic dotfile” on the RW fs to “mask” it. Setting up `unionfs` can be a little touchy, is why I'd suggested the LiveUSB (it does that part for you, and you have a “clean” system image to start from) – BRPocock Dec 28 '11 at 14:21
1

Use LD_PRELOAD to load a library that intercepts the open library function and changes the pathname / logs the output / makes a backup before opening the file.

Have a look at the source code for strace.

Ben Voigt
  • 473
  • 5
  • 20
0

If the installer uses some packaging facility (i.e. for .deb packages for Debian/Ubuntu/..., .rpm packages for RedHat/CentOS/... etc) then the package installer should know what to do on installation and on removal. And I believe you should use existing packaging systems, not invent your own one. (Linux conventionally don't have installers like Windows does).

If you really want to follow the file changes made by some process, you could use strace, or ltrace to catch system calls. You can also inotify and related facilities.

But I don't know of a catch-modifs & revert-modifs like you want.

I do suggest to not make an installer for your application, but to use the package manager, hence to provide .deb (and/or .rpm) packages for your application. They will handle the dependency issues better than your own installer.

Basile Starynkevitch
  • 222
  • 1
  • 4
  • Yes, I use apt-get all the time. I wasn't talking about my own applications, but about unpackaged ones. I don't always have a .deb at hand. –  Dec 27 '11 at 12:52
  • The unpackaged applications you mention should document what files they use and how they should be installed. –  Dec 27 '11 at 12:56
  • ^^ What if they don't? I knew I could package them myself, but it's not _straightforward_. Plus such commands could be useful to test in a safer way some system scripts you make. –  Dec 27 '11 at 12:59
  • I agree that your wish is interesting, but I am not sure if it is easily implementable.... –  Dec 27 '11 at 13:32
0

The easy way to achieve what you want: install the "untrusted" application in a brand-new virtual machine instance (VMWare workstation, Oracle VirtualBox, etc.).

When you decide you no longer want the application, delete the virtual machine.

Your other alternatives -- catching file access syscalls -- are likely going to be error prone and incomplete. Be especially wary of any solution that requires dynamic linking in order to work (as Installwatch appears to do). An installer can quite legitimately exercise direct system calls, or be statically linked.

  • Wow, virtual machine is definitely overkill... I just need to save and backup some configuration files in a convenient way. – Ywen Dec 28 '11 at 08:57