Bug #69536 [NEW]: Extracted ZipArchive archives have insecure permissions when extracted by OSX

From: kevin dot cupp at ellislab dot com Operating system: OSX PHP version: 5.5.24 Package: Zip Related Bug Type: Bug Bug description:Extracted ZipArchive archives have insecure permissions when extracted by OSX Description: ------------ In PHP 5.5 and above, ZipArchive is creating archives that, when extracted by OSX, have its folders permissions set to 777 and files set to 666. In PHP 5.4, everything defaults to 755. When using a third-party extractor, such as The Unarchiver for OSX, permissions are normal, so it is only a problem (to my knowledge) with OSX's native unarchiver. It could be argued that since it's a problem with OSX's unarchiver, the ball is in their court. But since it works fine on archives created in <= 5.4, I'm wondering if something could be done on PHP's end to write its zips in a way that OSX's unarchiver will not misinterpret, as a lot of folks are creating zips with PHP and a lot of customers are extracting those zips on their Macs. I'm not expecting original permissions be retained, just that ZipArchive writes its archives in a way that allows OSX pick a more sane default again, like 755. Test script: --------------- $zip = new ZipArchive(); $zip->open('./test.zip', ZIPARCHIVE::CREATE); $zip->addEmptyDir('archive'); $zip->addFile('./test.php', 'archive/test.php'); $zip->close(); Expected result: ---------------- I expect an archive to be created, that when extracted with OSX's native unarchiver, the files have a relatively secure default permission applied to them, as in PHP 5.4. Actual result: -------------- Extracted files have a permission of 666, folders are 777. -- Edit bug report at https://bugs.php.net/bug.php?id=69536&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=69536&r=trysnapshot54 Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=69536&r=trysnapshot55 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=69536&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=69536&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=69536&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=69536&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=69536&r=needscript Try newer version: https://bugs.php.net/fix.php?id=69536&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=69536&r=support Expected behavior: https://bugs.php.net/fix.php?id=69536&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=69536&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=69536&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=69536&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=69536&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=69536&r=dst IIS Stability: https://bugs.php.net/fix.php?id=69536&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=69536&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=69536&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=69536&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=69536&r=mysqlcfg