Localize our chroot in/out operations to minimize time spent inside

[pmatilai]

The primary motivation here is to consolidate all database accesses
on one side of the chroot, currently it happens on both sides of the
border causing all sorts of issues and limitations (such as preventing
us from using more advanced modes of databases).
As a positive side-effect, the sections where we potentially run
inside chroot are more easily identifiable.

Consolidating on the outside may seem counter-productive, to improve
security it seems you'd want to spend as much time in as possible,
including database accesses. Unfortunately due to rpm's access patterns
and API promises, that's not really achievable (tried several approaches,
run into as many dead-ends).

Technically we could localize the chroot placement much further, but
doing so would change the side for transaction callbacks, which could
cause nasty breakage for our API users as various clients use those
callback slots to update their own databases and logs. So the chroot
spots here are selected to cover minimum possible code while preserving
the chroot side of callbacks and plugin slots: RPMCALLBACK_INST_OPEN/CLOSE,
ELEM_PROGRESS and VERIFY_* occur outside the chroot, everything else inside.
Of plugin slots, init/cleanup and tsm_pre/post occur outside, everything
else inside.

[Conan-Kudo]

@pmatilai Is this something you want to also include for rpm 4.15?

[pmatilai]

Heavens forbid, no. Not at this point in the release process.

[pmatilai]

Hmph, there's an elephant or two in the room. Of course there is...

There are two major cases unresolved by this: fingerprinting, and rpm -V verification. Fixing verify is merely annoying, but fingerprinting is much harder and more intrusive as there are several far-apart places where we stat() stuff.

However those are always read-only accesses, which seems to be mostly harmless and nothing seems to mind. The cases where it matters are open, close and writing.

So at the very least, the commit message needs to clarify the chroot rules being laid out here, and that's what this is largely about: while rpm itself can generally be fixed to function on whichever side of chroot, that's not the case for external libraries we might call, and there's also our own API users and their external libraries that can be affected by all this.

[pmatilai]

Refactored into two commits to eliminate the indentation problem in the first version, and clarified commit message.

[pmatilai]

Since there are no further comments...

[mlschroe]

My only concern is that the password/group lookups in rpmug.c need to be done in the chroot, but you probably already checked that.