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 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.
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.
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.
*** This bug has been marked as a duplicate of 209442 ***