FSDB

seth vidal skvidal at phy.duke.edu
Tue Aug 12 04:56:18 UTC 2003


> There already exists rpmdb-redhat, which you can use (possibly from
> readonly media): 
> 
> rpm -V --dbpath /usr/lib/rpmdb/i386-redhat-linux/redhat/ foo
> 
> However a couple of caveats apply:
> 
> 1) This doesn't seem to be kept in sync with errata, which I can
> understand as if you have it installed it's an extra package to update
> each time, I guess you could have rpmdb-redhat-errata too.
> 2) You can't trust it on your system, but no reason you can't have it
> from ro media as it's static
> 3) You don't know you can trust your rpm binary, so I guess a statically
> linked one on ro media along with the db would be useful 
> 4) This possibly doesn't help with lkm/rootkits which may be able to do
> evil things intercepting your rpm calls.  I don't know of any that do
> this automagically (quick google), but certainly a bootable cd with rpm,
> rpmdb-redhat pluss errata db entries would be simple to maintain.

I think I mentioned this before but it would be a neat idea and it could
help with this problem:

have a db of the rpm headers for a long time back - this would be
dramatically smaller than keeping the actual files - on average an rpm
header is 1% the size of the rpm it is from.

so then you could do the following:
request that a check be done on package foobar on your system
that would - get the epoch,ver,release,arch from your rpmdb for that
package.
look up the header for that package in the remote headers. Download it.
Compare the files on your system to the file/md5sum list in the header
it downloaded. If they don't match return the failures.

If the remote header doesn't exist for the package you requested then 
name-epoch-ver-rel-arch then return a failure.

That way the only trust you'd have in your local rpmdb is to tell you
the ver of the package you have installed. And even then it wouldn't be
trusted for the file list.

seriously the functions that would need to be written to perform this
are not hard:

1. md5sum of files on your disk
2. system acl checks of files on your disk
3. matching and downloading hdrs from remote

everything else is interface and glue.

I think this would be a great project to work on if someone had some
time to devote to it.

maybe if I get some time later I'll try to work on it.
-sv






More information about the devel mailing list