Bug 253648 - rpmbuild in tarfile mode creates spec file with 0600 permissions, rpmlint complains
rpmbuild in tarfile mode creates spec file with 0600 permissions, rpmlint com...
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
7
All Linux
low Severity low
: ---
: ---
Assigned To: Panu Matilainen
Fedora Extras Quality Assurance
:
: 300761 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-20 18:54 EDT by John Dennis
Modified: 2008-04-22 09:25 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-22 09:25:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Dennis 2007-08-20 18:54:09 EDT
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 02:34:08 EDT
Reassigning to owner after bugzilla made a mess, sorry about the noise...
Comment 2 Panu Matilainen 2007-09-23 09:16:35 EDT
*** Bug 300761 has been marked as a duplicate of this bug. ***
Comment 3 Panu Matilainen 2008-04-22 09:25:02 EDT
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.

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