Bug 201640

Summary:	zip creates files with too-strict permissions
Product:	Red Hat Enterprise Linux 4	Reporter:	cody sparks <cody_sparks>
Component:	zip	Assignee:	Ivana Varekova <varekova>
Status:	CLOSED DUPLICATE	QA Contact:	Ben Levenson <benl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.0	CC:	varekova
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-10-11 08:56:35 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 cody sparks 2006-08-07 21:20:43 UTC

Description of problem: With umask set to 0000, zip-2.3-27 creates zip files
with permissions of 0644 instead of 0666.  Previous versions (zip-2.3-16 with
RHEL3 AS) created files with correct permissions.

Version-Release number of selected component (if applicable): 2.3-27


How reproducible: always


Steps to Reproduce:
1. umask 0022; touch test; zip file.zip test
 --- test permissions are 0644 and file.zip is 0644 (GOOD)
2. umask 0000; touch test2; zip file2.zip test2
 --- test2 permissions are 0666 and file2.zip is 0644 (BAD)
  
Actual results: zip appears to have a built-in umask of 0022 regardless of the
global umask.  Previous versions worked as expected (created files based on
global umask).


Expected results: new zip file created with permissions 0666 when umask is 0000.


Additional info: would have checked source to confirm, but src RPM is
unavailable for zip-2.3-27 at the time of bug submission from rhn.redhat.com.

Comment 1 Marcela Mašláňová 2006-08-09 14:18:00 UTC

Hello,
this restriction was included with patch. It was made for safer behaviour. 
Patch was made for bug #112516. So I close it like a notabug.

Comment 2 cody sparks 2006-08-09 15:08:23 UTC

These bug reports are unrelated.  The problem reported in bug #112516 is due to
insecure *temporary* files.  The file that I am speaking of is the new zip file
created.

I understand the need for temporary files to be secure, but shouldn't my
newly-created zip files follow my environmentally-set umask, as all other
newly-created files do?

In the previous bug report, the *temporary* files were world-readable (mode
644), and apparently the submitter wanted these temporary files to be mode 600.
 What I was expecting with this case is the newly-created zip files that a user
creates will be created with the permissions specified in that user's umask
environment variable.

Comment 3 Ivana Varekova 2006-10-11 08:56:35 UTC


*** This bug has been marked as a duplicate of 209442 ***