Red Hat Bugzilla – Bug 201640
zip creates files with too-strict permissions
Last modified: 2007-11-30 17:07:26 EST
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
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.
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.
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
*** This bug has been marked as a duplicate of 209442 ***