Using SQLIte database when working messing w/ chroot

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Using SQLIte database when working messing w/ chroot

Mark Hatle
I am working on using sqlite3 as a replacement database in RPM.

RPM has an option --root that will perform a chroot operation before
installing any files into the system.

This has presented itself as a problem.  RPM opens the database, does
some validation ... performs the chroot ... and then attempts to write
to the database.

SQL returns back "unable to open database file".  I tracked this down to
it attempting to open the journal based on the original path name and
not the chrooted path name.

Does anyone have any suggestions on how to solve this?  Inform sqlite of
the root portion of the path?  Temporarily disable the journal when the
chroot operation will be performed?  Or some other mechanism?

Right now I am thinking of teaching sqlite about the concept of a root
path that can be stripped based on if the chroot has been performed or
not.  But there may be a better way to do it then that.

Thank you!
--Mark
Reply | Threaded
Open this post in threaded view
|

Re: Using SQLIte database when working messing w/ chroot

Derrell Lipman
Mark Hatle <[hidden email]> writes:

> Does anyone have any suggestions on how to solve this?  Inform sqlite of
> the root portion of the path?  Temporarily disable the journal when the
> chroot operation will be performed?  Or some other mechanism?

Are you able to just close the database file prior to the chroot() and reopen
it afterwards?  If you can do that, it should solve this problem.

Derrell
Reply | Threaded
Open this post in threaded view
|

Re: Using SQLIte database when working messing w/ chroot

Mark Hatle
I am not completely sure.  Part of the problem is that in order to add
sqlite3 support into RPM, I needed to emulate the abilities of
BerkleyDB.  RPM has built-in assumptions as to what works and doesn't.

I am still looking into possibly modifying RPM to do the closeall,
reopen.. but I need to figure out "where".

--Mark

[hidden email] wrote:

> Mark Hatle <[hidden email]> writes:
>
>
>>Does anyone have any suggestions on how to solve this?  Inform sqlite of
>>the root portion of the path?  Temporarily disable the journal when the
>>chroot operation will be performed?  Or some other mechanism?
>
>
> Are you able to just close the database file prior to the chroot() and reopen
> it afterwards?  If you can do that, it should solve this problem.
>
> Derrell
>
Reply | Threaded
Open this post in threaded view
|

Re: Using SQLIte database when working messing w/ chroot

Mark Hatle
In reply to this post by Mark Hatle
Just an FYI, I figured out a solution.

In my BerkleyDB "emulation layer", I make sure we are inside of the
chroot before every sqlite call, and then return the state of the system
at the end of the call.

This seems to solve the problem, with only a bit of chroot overhead
occasionally.

Thanx,
Mark

Mark Hatle wrote:

> I am working on using sqlite3 as a replacement database in RPM.
>
> RPM has an option --root that will perform a chroot operation before
> installing any files into the system.
>
> This has presented itself as a problem.  RPM opens the database, does
> some validation ... performs the chroot ... and then attempts to write
> to the database.
>
> SQL returns back "unable to open database file".  I tracked this down to
> it attempting to open the journal based on the original path name and
> not the chrooted path name.
>
> Does anyone have any suggestions on how to solve this?  Inform sqlite of
> the root portion of the path?  Temporarily disable the journal when the
> chroot operation will be performed?  Or some other mechanism?
>
> Right now I am thinking of teaching sqlite about the concept of a root
> path that can be stripped based on if the chroot has been performed or
> not.  But there may be a better way to do it then that.
>
> Thank you!
> --Mark
>