On Sat, 12 Jun 1999, Brett Lymn wrote:

> This is what I am after, I was hoping for an online reference
> somewhere :-).  What I am doing at the moment is feeding md5
> signature/filename pairs into the kernel via a pseudo-device (the
> pseudo-device only accepts the pairs with securelevel <= 0).  The
> inode & dev numbers are stashed into lists.  On exec the lists are
> searched for the dev & inode pair and the associated signature
> compared against the one that has just been calculated (or fetched
> from cache).  From what I understand an associative hash table would
> mean a number of smaller lists that can be searched more quickly which
> means less negative impact on exec.  Another thing that occurred to me
> today was to shuffle the order of the contents of the lists so that
> the most often referenced entries migrate to the top of the signature
> list which would mean that frequently executed binaries would be found
> in the signature list more quickly.

Don't use dev / inode pairs - use filehandles. Filehandles include
generation #'s, so they'll catch replacing a file with another which dev /
inode pairs won't.

Also, what might be better is if the program included an id number. Stick
the id number in a seperate ELF section, and you're fine. Make it kinda
big, like 16 bytes or 32 bytes, and you shouldn't need to worry about
duplicates.

The big problem with either dev / inode pairs or filehandles is that they
don't support restoring files from a backup. With keeping the id in the
file, you can copy a binary and the copy still works (it's compared
against the same key). restore'd programs work, as do just cp'ing the file
somewhere else.

Take care,

Bill