Bug 205902 - Bad permissions in plague-generated packages
Summary: Bad permissions in plague-generated packages
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: plague
Version: rawhide
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-09-09 20:50 UTC by Ville Skyttä
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version: 0.4.4.1-2
Clone Of:
Environment:
Last Closed: 2006-09-14 16:21:59 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Ville Skyttä 2006-09-09 20:50:36 UTC
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 22:55:58 UTC
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 16:21:59 UTC
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.