Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 1133946 - rpmbuild started as root preserves file owner/group from tarball
rpmbuild started as root preserves file owner/group from tarball
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: packaging-team-maint
Fedora Extras Quality Assurance
: Upstream
Depends On:
Blocks: 1017034
  Show dependency treegraph
Reported: 2014-08-26 09:57 EDT by Jakub Jelen
Modified: 2014-09-30 06:05 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-09-30 06:05:29 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jakub Jelen 2014-08-26 09:57:12 EDT
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):
but also applicable on all Fedora, RHEL 6 and RHEL 7 versions of rpm

How reproducible:

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
Comment 1 Panu Matilainen 2014-08-27 01:57:58 EDT
How about: dont run rpmbuild as root. That is simply a very very bad idea.
Comment 2 Jakub Jelen 2014-09-07 14:12:25 EDT
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?
Comment 3 Panu Matilainen 2014-09-30 06:05:29 EDT
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: 

Note You need to log in before you can comment on or make changes to this bug.