Hide Forgot
If you use rpm --root <chroot> to install packages for a chroot and the chroot disappears while rpm is installing, it falls back to installing package content outside of the chroot. This can really hose your system. The version of rpm I am using is the one from U3: rpm-4.3.3-13_nonptl To replicate this in a safe way, I've done the following: 1) create a harmless set of test packages to install 2) created a base chroot to install them in 3) install the test packages in the chroot 4) while the test packages are installing, delete the chroot 5) verify that contest from the test packages has been installed outside of the chroot I've written a script that goes through these steps: ~mikem/rpm-chroot.sh The script has an strace option for running rpm through strace For step 4, I recommend using ~mikem/rmtree I will post some strace output shortly
Created attachment 129369 [details] strace of rpm showing this issue It looks like rpm may simply be ignoring the error code from a failed chroot: chdir("/") = 0 chroot("/var/lib/mock//test/") = -1 ENOENT (No such file or directory) time(NULL) = 1147903876 open("/var/tmp/rpm-tmp.61061", O_RDWR|O_CREAT|O_TRUNC|O_EXCL, 0666) = 8
in psm.c, chroot is called three times: in runScript, the return code is not checked in rpmpsmStage (two instances), the return code of the chroot is returned from the function, but I'm not sure how it is handled further up the line in transaction.c, chroot is called twice in the function rpmtsRun. The return code is not checked.
jkeating mentioned that brew is using a patched rpm that avoids this problem. Is this true?
No, brew is not using a patched rpm. Once we understood the nature of the problem, we were able to avoid triggering the bug.
In most cases, there's little risk, as chroot is root-only, the build tree is owned by root.root and so cannot be removed, and the outer file system is owned root.root, etc. But yes, the chroot return code needs to be checked.
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. Please See https://access.redhat.com/support/policy/updates/errata/ If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.