> I believe this is not true. I see no code in rpmbuild that would elevate UID
> to root. Nor any consolehelper. Nor setuid bits.
In the container.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3005#issuecomment-2036268291
You are
What I mean is rpm's own test-suite:
https://github.com/rpm-software-management/rpm/blob/5d4a476d14998f8f7ebc7e0c15a5263ca7803f5d/tests/mktree.oci#L53
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3005#issuecomment-2035694448
You are
> we're running the entire test-suite as root.
I believe this is not true. I see no code in rpmbuild that would elevate UID to
root. Nor any consolehelper. Nor setuid bits.
--
Reply to this email directly or view it on GitHub:
Sounds like a plan :+1:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3005#issuecomment-2024754579
You are receiving this because you are subscribed to this thread.
Message ID: ___
Bonus point - `runroot` will finally live up to its name :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3005#issuecomment-2024750126
You are receiving this because you are subscribed to this thread.
Message ID:
Yup, good point. I think we should actually make the `rpmtests` script (which
runs in the podman container) run as a regular user there. The individual tests
aren't supposed to write to the root filesystem anyway (which we prevent by
making it read-only) so being root shouldn't be necessary
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
