RFE: execute rpmbuild tests as a regular user #3005
Comments
|
Yup, good point. I think we should actually make the Then, when a test actually needs to write to the system, e.g. to install a package (and thus needs root privileges), we can escalate it (via So, that means, those tests that run |
|
Bonus point - |
|
Sounds like a plan 👍 |
Packages may contain files without write permissions, read-only sources and whatnot. Run %_fixperms on the whole builddir before trying to remove it to ensure we don't fail doing our household duties. It's worth noting that prior to b5f6c64 the build could similarly fail while running it's default %clean. If we hadn't removeed the default %clean, we'd have to do this permission fixup first redundantly for the build root and then for the rest of the %builddir. Also worth noting is that the added test doesn't actually reproduce the issue in the test-suite because it runs as root and root is not bothered by such petty issues as missing read/write permissions to remove. But at least we have a reproducer for the case once rpm-software-management#3005 is done. Fixes: rpm-software-management#2519
Packages may contain files without write permissions, read-only sources and whatnot. Run %_fixperms on the whole builddir before trying to remove it to ensure we don't fail doing our household duties, both on post-cleanup but also before trying to remove an old run, as eg 'rpmbuild -bi' will not run cleanup. It's worth noting that prior to b5f6c64 the build could similarly fail while running it's default %clean. If we hadn't removeed the default %clean, we'd have to do this permission fixup first redundantly for the build root and then for the rest of the %builddir. Also worth noting is that the added test doesn't actually reproduce the issue in the test-suite because it runs as root and root is not bothered by such petty issues as missing read/write permissions to remove. But at least we have a reproducer for the case once rpm-software-management#3005 is done. Fixes: rpm-software-management#2519
I believe this is not true. I see no code in rpmbuild that would elevate UID to root. Nor any consolehelper. Nor setuid bits. |
|
What we mean here is rpm's own test-suite: Line 53 in 5d4a476 |
Root, in the container. |
Packages may contain files without write permissions, read-only sources and whatnot. Run %_fixperms on the whole builddir before trying to remove it to ensure we don't fail doing our household duties, both on post-cleanup but also before trying to remove an old run, as eg 'rpmbuild -bi' will not run cleanup. It's worth noting that prior to b5f6c64 the build could similarly fail while running it's default %clean. If we hadn't removeed the default %clean, we'd have to do this permission fixup first redundantly for the build root and then for the rest of the %builddir. Also worth noting is that the added test doesn't actually reproduce the issue in the test-suite because it runs as root and root is not bothered by such petty issues as missing read/write permissions to remove. But at least we have a reproducer for the case once rpm-software-management#3005 is done. Fixes: rpm-software-management#2519
Packages may contain files without write permissions, read-only sources and whatnot. Run %_fixperms on the whole builddir before trying to remove it to ensure we don't fail doing our household duties, both on post-cleanup but also before trying to remove an old run, as eg 'rpmbuild -bi' will not run cleanup. It's worth noting that prior to b5f6c64 the build could similarly fail while running it's default %clean. If we hadn't removeed the default %clean, we'd have to do this permission fixup first redundantly for the build root and then for the rest of the %builddir. Also worth noting is that the added test doesn't actually reproduce the issue in the test-suite because it runs as root and root is not bothered by such petty issues as missing read/write permissions to remove. But at least we have a reproducer for the case once #3005 is done. Fixes: #2519
While investigating #2519 I realized that we're running the entire test-suite as root. That's not how rpmbuild is intended to be used, and masks various permission issues real-world users have, such as that #2519 which is not reproducable in the test-suite because of this.
Adding a user to the test-environment is trivial enough, actually running the tests with it probably less so. Besides all rpmbuild tests, there's probably a lot of other tests too that would optimally run as non-root.
The text was updated successfully, but these errors were encountered: