Public SourceMage Discussion List

[Andrew <afrayedknot AT thefrayedknot.armory.com>]

Oops, let me add a minor pedantic correction.

installwatch overrides standard system calls so the application thinks
its talking to glibc, when in reality its talking to installwatch, which
then does the actual call to glibc which then calls the into the kernel.

On Mon, May 15, 2006 at 10:10:04PM -0700, Andrew wrote:
> I'll provide some more context/background for this.
> 
> In all previous sorcery versions we've used a program called installwatch
> to log file operations. What installwatch does is sit between the kernel
> and glibc (which basically everything uses to manipulate files). It can
> then observe everything that happens*. During the installation phase of
> a spell, sorcery enables installwatch, which then logs what files get
> created or modified. From this it generates the install log.
> 
> In a more recent version of installwatch, they have added a feature
> where instead of just logging file operations, it transparently redirects
> the file operations to some other directory. So for example a spell could
> install a file to /usr/bin. Installwatch would redirect that
> to /usr/src/stage-root/usr/bin (or somewhere similar). Future programs
> running in the same install phase will still see the /usr/bin file as if its
> actually there.
> 
> Think of it as a lowest common denominator approach to INSTALL_ROOT.
> 
> Along with that, we can now do things we couldn't previously do. For
> example config files won't get accidentally overwritten. Spell writer's
> wont have to use install_config_file as much.  It makes creating chroot's
> with arbitrary nearly unmodified spells possible (using spells other
> than in basesystem or that support INSTALL_ROOT). Failure's during the
> install phase no longer pollute the system. The list goes on, but these
> are the immediate benefits.
> 
> -Andrew
> 
> * We cannot guarantee it will get everything, someone could use a
> static binary, or directly trap the kernel into a syscall, or use another
> C library. In practice that doesn't happen often. To truly get everything
> you'd need to put something in the kernel. However, tools implementing
> that seem to hurt performance way too much to justify their use.
> 
> -- 
> _________________________________________________________________________
> | Andrew D. Stitt  | acedit at armory.com    | astitt at sourcemage.org | 
> | irc: afrayedknot | Sorcery Team Lead       |      ftp://t.armory.com/ |
> | 1024D/D39B096C   | 76E4 728A 04EE 62B2 A09A 96D7 4D9E 239B D39B 096C  |
> -------------------------------------------------------------------------
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss

-- 
_________________________________________________________________________
| Andrew D. Stitt  | acedit at armory.com    | astitt at sourcemage.org | 
| irc: afrayedknot | Sorcery Team Lead       |      ftp://t.armory.com/ |
| 1024D/D39B096C   | 76E4 728A 04EE 62B2 A09A 96D7 4D9E 239B D39B 096C  |
-------------------------------------------------------------------------