Zipfile._extract_member does not preserve file permissions while extracting it. As may be seen at link[1], raw open() is used and no os.chmod() applied after that, therefore any permission data stored in zipfile is dropped and file is created with default permission depending on current user's umask.

[1] http://hg.python.org/cpython/file/52159aa5d401/Lib/zipfile.py#l1251

Does this have any relationship to issue 3394?  From the discussion on that issue it sounds like zipfile is doing things with external_attributes if it is set.  But I don't know much about zipfile internals.

I'm attaching a patch, which solves the issue. Patch intoduces new argument "preserve_permissions" for extract and extractall methods. That argument may accept one of the three values: do not preserve permissions, preserve a safe subset of them or preserve all permissions. Three constants introduced for these options. Patch also contains test and docs. Tests pass for me on OS X 10.5, but I'm not sure if they'll pass on other operating systems.

Thanks for the patch. Is this going to be resolved soon?

OK, so this is an enhancement to specifically allow preservation of "unsafe" permissions?

Adding the nosy list from issue 3394.

There should be an easy way to restore file attributes.

On first glance the patch looks good. I haven't tested it with the current trunk though.

Here is an updated patch that applies cleanly to head. Tests pass against head of repo.

Thanks.

The patch contains a number of lines that are not wrapped to <80, which is one of our requirements.  It would be great to get that fixed.  (In the documentation, you can use \ to wrap the prototype line.)

There is non-ascii in one place in the documentation...probably an em-dash, which is written in sphinx as '---'.

Also, please remove the news entry from the patch, it will just make it harder to apply (and is in the wrong place anyway...we add entries at the top of the appropriate section, not the bottom).

Patch cleaned up based on previous comments.

Hello. I added a couple of comments to your latest patch.

Patch with docs and tests fixed

The TarFile.extract() method has the set_attrs parameter which controls similar behavior but is less flexible. It would be good to unify zipfile and tarfile abilities. set_attrs also controls setting file owner and time. When we restore unsafe uid/gid/sticky bits, it would be worth to restore also file owner. And it would be not bad to restore file time.

I hope this can be finally gotten in for 3.5, even if it's not the perfect solution.  I hit this issue and needed to call out to a subprocess as a work-around, but that's far less reliable.

I'm working on updating the patch to unify tarfile and zipfile interfaces and to restore owner/timestamp for zipfile

same problem in 2.7.5 on Oracle Linux 7.2

Note the zipfile being processed may have been created on a non-Unix system, and the external_attr value can't be usefully interpreted as permission bits when the value at _CD_CREATE_SYSTEM (https://hg.python.org/cpython/file/default/Lib/zipfile.py#l107) in the central directory entry is not Unix (3). Patches so far don't seem to guard against mistakenly assuming a foreign-system external_attr value can be interpreted as Unix permission bits.

(At present github is delivering zipfiles of repos with a create system value of 0 and external_attr values of 0.)

A workaround is provided here: https://stackoverflow.com/questions/39296101/python-zipfile-removes-execute-permissions-from-binaries

Is there any chance that the pull request will be accepted? I'm a bit tired of using workaround every time I need unzip something on linux.

The pull request needs unit tests added to validate the changes.

Note that the patch attached here was a new feature, adding constants and parameters to control the behaviour, but the PR simply checks and applies permissions bits stored in the entry.  That seems correct and nice to me, and arguably a bugfix that should be backported, but more active core devs and/or zipfile experts should weigh in.