[Yum-devel] [PATCH] Fix rpm chroot insanity, so we can access the history DB from unInstStop() cb.

Panu Matilainen pmatilai at laiskiainen.org
Thu Jun 23 06:03:02 UTC 2011

On 06/23/2011 01:42 AM, James Antill wrote:
>   So the problem is that AGAIN, when we log stuff for installed rpms we
> do it in _instCloseFile, which is outside the chroot ... but when we log
> stuff for erase rpms we do it in _unInstStop, which is inside the
> chroot.
>   sqlite will open it's journal file, which is it has a working path for
> from outside the chroot ... being inside the chroot breaks this, which
> results in complete failure of everything.
>   Proposed fix is to move out of the chroot, before we call the
> history/sqlite APIs, and then move back out again ... basically what rpm
> does. Seems to work.
> ---
>   yum/rpmtrans.py |    6 ++++++
>   1 files changed, 6 insertions(+), 0 deletions(-)
> diff --git a/yum/rpmtrans.py b/yum/rpmtrans.py
> index 400d729..e0b7058 100644
> --- a/yum/rpmtrans.py
> +++ b/yum/rpmtrans.py
> @@ -551,9 +551,15 @@ class RPMTransaction:
>           if txmbr is not None:
>               self._scriptout(txmbr.po)
> +            #  Note that we are now back outside the smegging chroot, which

Should be inside, right?

> +            # confuses the heck out of sqlite when it tries to open it's journal
> +            # file. So let's have fun:
> +            os.chroot(".")
>               pid   = self.base.history.pkg2pid(txmbr.po)
>               state = self.base.history.txmbr2state(txmbr)
>               self.base.history.trans_data_pid_end(pid, state)
> +            os.chroot(self.base.conf.installroot)
> +
>               self.ts_done(txmbr.po, txmbr.output_state)
>           else:
>               self._scriptout(name)

Lets just say I'm not at all comfortable with the idea of chroot 
switcheroo behind rpms back in a callback.

Of course rpm can't prevent anybody from doing this, if you really 
intend to go this way then at least be careful about it: you'll only 
want to chroot if the operation was chrooted to begin with. Since either 
chroot failing (unlikely but possible technically) would cause an 
exception and a sudden death I guess there's no need for error checking. 
The process cwd might be in a bit of a la-la-land between the chroot 
calls but at least current sqlite doesn't seem to use cwd for anything 
so maybe it doesn't matter...

	- Panu -

More information about the Yum-devel mailing list