[Rpm-maint] [rpm-software-management/rpm] Localize our chroot in/out operations to minimize time spent inside (#836)

Panu Matilainen notifications at github.com
Fri Sep 13 11:08:36 UTC 2019

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.
You can view, comment on, or merge this pull request online at:


-- Commit Summary --

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

-- File Changes --

    M lib/psm.c (66)
    M lib/rpmtriggers.c (12)
    M lib/rpmts.c (2)
    M lib/transaction.c (5)

-- Patch Links --


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20190913/d72bee33/attachment-0001.html>

More information about the Rpm-maint mailing list