Bug 201640 - zip creates files with too-strict permissions
zip creates files with too-strict permissions
Status: CLOSED DUPLICATE of bug 209442
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: zip (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ivana Varekova
Ben Levenson
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2006-08-07 17:20 EDT by cody sparks
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-11 04:56:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description cody sparks 2006-08-07 17:20:43 EDT
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 10:18:00 EDT
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 11:08:23 EDT
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

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 04:56:35 EDT

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

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