Bug 200355 - mock installing SRPM files mode 0666
mock installing SRPM files mode 0666
Status: CLOSED NOTABUG
Product: Fedora Hosted Projects
Classification: Retired
Component: mock (Show other bugs)
unspecified
All Linux
medium Severity high
: ---
: ---
Assigned To: Clark Williams
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-26 23:13 EDT by Stan Bubrouski
Modified: 2013-01-09 23:01 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-30 11:40:42 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 Stan Bubrouski 2006-07-26 23:13:55 EDT
When rebuilding/installing Extras SRPMS as root it creates SPEC files, patches,
tar.gz files, etc... mode 0666... why do this?  Why not use root's umask?
Comment 1 Stan Bubrouski 2006-07-26 23:24:41 EDT
I should also mention it behaves the same way with regular users as well.
Comment 2 Clark Williams 2006-08-10 17:34:35 EDT
Well, nowhere in mock is there a call to chmod. The only permission modifying
call is one to os.umask(0022), which means the default creation permission of
for mock is 0644 (rw-r--r--). 

It's possible that someone is calling "mock-helper chmod 0666" on things, but
that's not happening in mock (possibly plague?).

Why is 0666 a problem for the results?
Comment 3 Stan Bubrouski 2006-08-10 19:27:54 EDT
Okay for instance, grab the imlib2 srpm from extras and install it.  The SPEC
file, the .tar.gz file and the patch with it will all be in
/usr/src/redhat/{SPECS|SOURCES} installed mode 0666.  I've tried several
packages from extras all with the same result.  If anyone can replace patches,
spec files, sources, etc... it can't be a good thing.  This happens regardless
of the umask of the user.
Comment 4 Clark Williams 2006-08-30 11:40:42 EDT
Ah, took me a while to realize you're talking about installing an SRPM, so the
program creating the files is rpm, not mock.

The permissions for files in the SRPM will be the same as they were on the
filesystem when the SRPM was created, so there's not really anything you can do
about that. I have a variety of SRPMs installed on my system and the
permisssions of the components (specfile, sources, patches) all vary wildly.
Interestingly, I don't see any 0666 ones though.

This is not a bug in mock. You might be able to make an argument that rpm needs
to change permissions, but I don't think it's worth a change in rpm behavior.
Comment 5 Toshio Kuratomi 2006-08-30 11:56:34 EDT
I can confirm this problem on packages built through plague.  I downloaded my
recent build of python-docutils from  
http://buildsys.fedoraproject.org/plague-results/fedora-development-extras/

and got this::

$ rpmlint python-docutils-0.4-3.fc6.src.rpm
W: python-docutils strange-permission docutils-0.4.tar.gz 0666
W: python-docutils strange-permission python-docutils.spec 0666

The files checked out from cvs have 0664 permissions.  The srpm build through a
local mock run have 0664.  So this looks like a plague bug to me.

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