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?

Improve this question

6 Answers 6

Reset to default
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."

Improve this answer
2
  • 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, 2011 at 8: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, 2011 at 14:21
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.

Improve this answer
1

Take a look at Installwatch:

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

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

Improve this answer
4
  • You mean "CheckInstall"? Does it work when I don't have makefiles? In my case (Eclim) the installation was made through a jar installer.
    – Ywen
    Dec 27, 2011 at 13:03
  • No, I mean Installwatch which is a part of CheckInstall.
    – qerub
    Dec 27, 2011 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, 2011 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.
    – Ywen
    Dec 27, 2011 at 15:28
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.

Improve this answer
1
  • Yes, but as someone said, what if the program is statically linked?
    – Ywen
    Dec 28, 2011 at 9:01
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.

Improve this answer
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.
    – Ywen
    Dec 27, 2011 at 12:52
  • The unpackaged applications you mention should document what files they use and how they should be installed.
    – Basile Starynkevitch
    Dec 27, 2011 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.
    – Ywen
    Dec 27, 2011 at 12:59
  • I agree that your wish is interesting, but I am not sure if it is easily implementable....
    – Basile Starynkevitch
    Dec 27, 2011 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.

Improve this answer
1
  • Wow, virtual machine is definitely overkill... I just need to save and backup some configuration files in a convenient way.
    – Ywen
    Dec 28, 2011 at 8:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .