Please help: how to relocate installed files paths into an RPM database

[devzero2000]

On Wed, Aug 12, 2009 at 5:23 PM, <Greg_Swift at aotx.uscourts.gov> wrote:

> >
> > > I tried your suggestion and it works, however, since it implies
> > > reinstalling all the packages from their RPM files, though in
> > > database only, is no so different from reinstalling them completely.
> > > If no standard solution is available, I was looking for a sort of
> > > hack such as a query to manipulate the database directly. I guess
> > > RPM development team should take this in consideration because it
> > > allows a better portability of every RPM-based installation.
>
> > Well, depending on any changes you've made and how big the install base
> is,
> > it can be a lot smaller and quicker to perform.  I think some would argue
> > that having an easy direct way of manipulating the database would defeat
> > some of the purpose of the security the RPM database helps provide.
> > In ALL the security text i have read - FWIW i am also a CEH - the
> > integrity check offered by the command rpm -V it is considered
> > having little, if any, importance from a "security" point of view..
> > And not because it is or  not so easy change an rpmdb but rather
> > because the database - the rpmdb -  from which the verification is
> > done is put  on the same local machine. It would be equivalent to
> > have the aide db on the same machine on which aide do the check:
> > just for the paranoid  the same aide may have been changed for
> > hiding track o change. Hence the birth of products which carry out
> > such checks in a centralized manner, by placing also little
> > confidence using program staticaly linked for doing the security
> > integrity check (for example http://rfc.sf.net)
>
> very good point.
>
> > >
> > > Take for instance this scenario:
> > >
> > > A hacker gets on my box and does a relocate of an important package
> (like
> > > procps) to a directory outside of everyone's path, and then drop
> installs a
> > > custom rpm with a name like procps- that provides similar files, but
> with
> > > malicious content.  A rpm -qaV show the files all validating fine, and
> a
> > > rpm -q --whatprovides shows something that looks right... it isn't a
> pretty
> > > thought.
> >
> > > Although... i'm not sure if procps is relocatable.  But i think the
> point
> > > still stands.
> >
> > I can always do a --badreloc anyway.
>
> I just read the man page for badreloc, but i'm still not sure I get what it
> is for... could you expand on that?
>

Sure

If you try , for example

rpm -Uvh --relocate /=/usr/local --badreloc somepkg*.rpm

then all the directories / files can be relocated. Clearly, it is possible
that arise some problem if you want relocate AND update the package AND
exists  file dependencies of other packages from the previous location of
the files of the previous package: in this case is not possible to relocate
AND update, without changing the file deps of the other package. In this
case not even consider that you can use a - nodeps update :=)

hth



> -greg
>
> _______________________________________________
> Rpm-list mailing list
> Rpm-list at lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-list/attachments/20090812/254f764d/attachment-0001.htm>