Bug 205902 - Bad permissions in plague-generated packages
Bad permissions in plague-generated packages
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: plague (Show other bugs)
rawhide
All Linux
medium Severity high
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-09 16:50 EDT by Ville Skyttä
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: 0.4.4.1-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-14 12:21:59 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 Ville Skyttä 2006-09-09 16:50:36 EDT
plague's common/daemonize.py has:

         # Give the child complete control over permissions.
         os.umask(0)

Apparently because of this, the umask is still 0000 when the cvs checkout/make
srpm is done, and this affects the resulting packages.

First, all contents of source rpms coming from plague have world writable
permissions, see any FE SRPM, for example:

$ rpm -qlvp
http://download.fedora.redhat.com/pub/fedora/linux/extras/5/SRPMS/CastPodder-5.0-6.fc5.src.rpm
-rw-rw-rw-    1 mockbuilmockbuil          577 Jun 22 02:59 CastPodder-16.png
-rw-rw-rw-    1 mockbuilmockbuil         1243 Jun 22 02:59 CastPodder-32.png
-rw-rw-rw-    1 mockbuilmockbuil         1651 Jun 22 02:59 CastPodder-48.png
-rw-rw-rw-    1 mockbuilmockbuil       894021 Jun 22 02:59 CastPodder-5.0.tar.bz2
-rw-rw-rw-    1 mockbuilmockbuil         5354 Jun 22 02:59 CastPodder.spec

Second, these world writable permissions may trickle into binary packages too if
one does things like "cp -p %{SOURCEX} ..." for copying files around during the
build - this is a security issue.

As far as the binary packages are concerned, it is kind of a packaging bug too
and a lot of FE packages have been fixed recently by adding explicit modes when
copying %{SOURCEx} around, but there's nothing one can do about the
files-in-SRPMS permissions and depending on the setup, that might be a security
issue too.

Note that there's also an OTRS ticket about this open for this since end of
July, ticket id 78.
Comment 1 Dennis Gilmore 2006-09-11 18:55:58 EDT
I think we should set the umask to 0002 

I have been running plague with the umask at 0022  and not seen any errors 
from this  however it doesn't work nicely with the extras push scripts  which 
rely on group privileges.  so it would be saner to use 0002.

i grabbed a freshly built SRPM  just before  and 
[dennis@rpclnx001 ~]$ rpm -qlvp Desktop/xbase-2.0.0-6.fc6.src.rpm
-rw-rw-r--    1 mockbuilmockbuil          356 Jul 10  2005 
xbase-2.0.0-fixconfig.patch
-rw-rw-r--    1 mockbuilmockbuil          402 Jun  4 08:43 
xbase-2.0.0-fixheader.patch
-rw-rw-r--    1 mockbuilmockbuil       430048 Jul  4  2005 xbase-2.0.0.tar.gz
-rw-rw-r--    1 mockbuilmockbuil         2513 Sep 11 17:14 xbase.spec
 
This package hasnt been released yet but was built this afternoon
Comment 2 Dennis Gilmore 2006-09-14 12:21:59 EDT
i have commited changes to cvs setting the default umask to 0002 builds have 
been requested for all branches.

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