Bug 253648

Summary: rpmbuild in tarfile mode creates spec file with 0600 permissions, rpmlint complains
Product: [Fedora] Fedora Reporter: John Dennis <jdennis>
Component: rpmAssignee: Panu Matilainen <pmatilai>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 7CC: notting, tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-04-22 13:25:02 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description John Dennis 2007-08-20 22:54:09 UTC
if one creates a src rpm from a tar file, e.g.:

rpmbuild -ta foo.tar.gz

then foo-x.x-x.src.rpm will contain a spec file whose permissions are 0600
despite the spec file in the tar ball having different permissions (e.g. 0644).

If one then runs rpmlint on the resulting foo-x.x-x.src.rpm it will complain the
mode of the spec file is 0600 and suggest it be 0644 instead (but the spec file
did have 0644 in the input tarball!)

I tracked down the reason this happens. The relevant code is in ./build.c in the
function buildForTarget(). The code creates a temp file for the spec file it is
going to read from the tarball:

	tmpSpecFile = rpmGetPath("%{_specdir}/", "rpm-spec.XXXXXX", NULL);
#if defined(HAVE_MKSTEMP)
	(void) close(mkstemp(tmpSpecFile));
#else
	(void) mktemp(tmpSpecFile);
#endif

then the spec file is extracted to the temp file by calling tar and redirecting
stdout to the temp file:

	sprintf(cmd, "%s < %s | tar xOvf - Specfile 2>&1 > %s",
-or-
	sprintf(cmd, "%s < %s | tar xOvf - --wildcards \\*.spec 2>&1 > %s",


then the temp file is renamed to the spec file in _specdir.

The problem arises because of the use of mkstemp() which enforces 0600
permissions. The file is renamed to be foo.spec and retains its 0600
permissions. This file is then copied into the resulting .src.rpm with the 0600
permissions mkstemp() gave it.

The expected behavior would be for the spec file to retain the permissions it
had in the tar file or for it to be given 0644 permissions to stay in alignment
with the expectations of rpmlint.

Comment 1 Panu Matilainen 2007-08-22 06:34:08 UTC
Reassigning to owner after bugzilla made a mess, sorry about the noise...

Comment 2 Panu Matilainen 2007-09-23 13:16:35 UTC
*** Bug 300761 has been marked as a duplicate of this bug. ***

Comment 3 Panu Matilainen 2008-04-22 13:25:02 UTC
I don't think rpmlint has any business telling anybody what the protection on
their files should be. However the 0600 mode from mkstemp() doesn't make much
sense in this case either - upstream rpm now honors the users umask for the
permissions of the spec fetched out of tarball. Which in default Fedora setup
happens to end up with the permissions rpmlint expects.