Description of problem: We run into this error after investigating problems with upstream testsuite and we traced it back to rpm which is calling tar. Problem is, that tar has default behaviour for superuser, that he sets -p option (and few more) and causes creation of files with original uid/gid which can cause problems. Version-Release number of selected component (if applicable): rpm-4.12.0-0.beta1.5.fc22.x86_64 but also applicable on all Fedora, RHEL 6 and RHEL 7 versions of rpm How reproducible: deterministic Steps to Reproduce: (Example with sudo) 1. Download source rpm 2. Run rpmbuild --rebuild sudo-*.src.rpm 3. See ll ~/rpmbuild/BUILD/sudo-*/README Actual results: -rw-r--r--. 1 8036 wheel 3825 Sep 18 2012 README Expected results: -rw-r--r--. 1 root root 3825 Sep 18 2012 README I propose to add another option to extract files in this line: > /usr/bin/tar -xf - if user is root, to overwrite "--no-same-owner" to force owner overwrite Additional info: As internal reproducer, we can use rhts test /CoreOS/sudo/Sanity/upstream-testsuite-execution-and-rebuild-test
How about: dont run rpmbuild as root. That is simply a very very bad idea.
I know, that is not a good idea to run rpmbuild as root since I have some experience in security team, but it is not the solution. As I mentioned above, all RHTS tests are running under root user. There is a way to workaround this with running this rpmbuild as other user using sudo, but this is not a bugzilla about rhts tests, but about rpm. Yes, you are of course right, that rpmbuild shouldn't be run as user, but if you do, is this the desired behaviour? Or shouldn't be mentioned somewhere somewhere that this is your desired behaviour?
After mulling over it a bit... Behaving differently for root is not only inconsistent but might even encourage for bad practises such as relying on building as root instead of setting the ownership in spec. Fixed upstream now: http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=9b9e0ca4d473cbe0e1116e8c7bd49c63f531fbb4