If you're reporting an issue for setuptools 0.7 or higher, please use BitBucket

Title permission error in untarring pyOpenSSL-0.6.tar.gz
Priority bug Status resolved
Superseder Nosy List pje, zooko
Assigned To zooko Keywords

Created on 2008-05-30.18:29:21 by zooko, last changed 2009-10-19.19:37:17 by pje.

msg429 (view) Author: pje Date: 2009-10-19.19:37:17
setuptools 0.6c10 is released with fixes for this issue.
msg390 (view) Author: pje Date: 2009-10-10.23:53:06
Could you please verify whether this fix (in the 0.7a1 trunk) is working
correctly?  I'd like to backport to 0.6 and close this ASAP.  Thanks.
msg94 (view) Author: pje Date: 2008-08-21.18:17:47
Candidate fix in trunk r65946; please test ASAP to confirm it is an actual fix.
msg28 (view) Author: zooko Date: 2008-05-31.15:32:28
The python folks have closed as "works for me",
saying that setuptools should use the public API of tarfile instead of the
internal _extract_member() method, or else setuptools needs to catch and ignore
(some?) ExtractErrors.
msg26 (view) Author: zooko Date: 2008-05-30.23:20:25
Okay, now for how to work around problems such as this in setuptools.

Suppose we put out setuptools v0.6c9, and suppose that someone uses that, while
using the current version of python 2.5 -- v2.5.2 -- the current
pyOpenSSL-0.6.tar.gz tarball (i.e. it is not rebuilt to be free of g+s bits),
then would it be worth it for setuptools to catch exceptions from its invocation
of and attempt to fall back to invoking a "tar" executable in a
msg25 (view) Author: zooko Date: 2008-05-30.22:56:03
Okay here is the ticket for the Python folks (re:
msg24 (view) Author: zooko Date: 2008-05-30.22:03:21
Okay, here is the ticket for the pyOpenSSL folks:
msg23 (view) Author: zooko Date: 2008-05-30.19:31:31
No, it turns out that the user id of the person who made the tarball is not the
differentiating factor -- a different user on this computer can untar the remade

Okay, diffing the output of "tar xzvvf" shows that the read-only quality of is not different, but that the only difference in output
(ignoring the username) is that in the official pyOpenSSL tarball the
directories all have the g+s bit on.

I can reproduce this problem by using chmod to set the g+s bit on the
directories and then packing up a tarball -- the resulting tarball incurs this
exact same exception when I try to easy_install it.  If I then use chmod to set
g-s and build a new tarball, the resulting tarball works.


1.  Would the maintainers of pyOpenSSL please build a new tarball of
pyOpenSSL-0.6.tar.gz without any g+s bits?

2.  Would the maintainers of please make it so that mashes
the g+s bit away on unpack, the same way that GNU tar v1.14 does on unpack?

3.  Would the maintainers of setuptools please think of some clever workaround
to make setuptools v0.6c9 successfully unpack the current pyOpenSSL-0.6.tar.gz
using the current

(That last one seems hard, but PJE and company are pretty clever.)

msg22 (view) Author: zooko Date: 2008-05-30.18:31:47
Oh, in msg20 I wrote "doesn't have read permissions for user or group", but I
meant doesn't have read permissions for group or other.
msg21 (view) Author: zooko Date: 2008-05-30.18:30:58
Oh, perhaps the reason that repacking the tarball made this problem stop
happening for me is that it changed the "user" on those files to be my user id
so I didn't experience the permissions problem on a subsequent unpack.  I will
msg20 (view) Author: zooko Date: 2008-05-30.18:29:20
Running easy_install on pyOpenSSL-0.6.tar.gz ends with:

line 626, in install_eggs
    unpack_archive(dist_filename, tmpdir, self.unpack_progress)
line 67, in unpack_archive
    driver(filename, extract_dir, progress_filter)
line 192, in unpack_tarfile
    tarobj._extract_member(member,dst)  # XXX Ugh
line 1656, in _extract_member
    self.chmod(tarinfo, targetpath)
line 1777, in chmod
    raise ExtractError("could not change mode of %s to mode %o (octal),
exception: %s" % (targetpath, tarinfo.mode, e))
tarfile.ExtractError: could not change mode of
/tmp/easy_install-4yCggq/pyOpenSSL-0.6 to mode 2755 (octal), exception: [Errno
1] Operation not permitted: '/tmp/easy_install-4yCggq/pyOpenSSL-0.6'

If I untar that tarball with GNU tar, I see that there is one file that doesn't
have read permissions for user or group:

-rw-r--r-- martin/martin   1289 2002-09-07 09:28:12
-rw-r--r-- martin/martin   1863 2004-07-22 06:01:25 pyOpenSSL-0.6/examples/
-rw------- martin/martin   3508 2002-09-07 09:27:47
-rw-r--r-- martin/martin    260 2004-07-22 06:01:25 pyOpenSSL-0.6/

If I rebuild that tarball with GNU tar ("tar czvvf pyOpenSSL-0.6.tar.gz
pyOpenSSL") then the resulting tarball does not have that problem.

So, I don't understand it, but there is something funny in the permissions in
that official pyOpenSSL-0.6.tar.gz (from ) which causes this
exception inside tarfile but which goes away if you unpack and repack the
tarball on Mac OS X using GNU tar v1.14.

This is probably more of a bug in than in setuptools proper, but I
thought I should register this issue on the setuptools tracker so that we can
think of some workaround to deploy before this gets fixed in Python
and everyone in the world upgrades to the new
Date User Action Args
2009-10-19 19:37:17pjesetstatus: testing -> resolved
messages: + msg429
2009-10-10 23:53:06pjesetmessages: + msg390
2008-08-21 18:17:47pjesetstatus: chatting -> testing
assignedto: zooko
messages: + msg94
keyword: - needpatch
nosy: + pje
2008-08-05 15:06:31pjesetkeyword: + needpatch
2008-05-31 15:32:29zookosetmessages: + msg28
2008-05-30 23:20:26zookosetmessages: + msg26
2008-05-30 22:56:05zookosetmessages: + msg25
2008-05-30 22:03:21zookosetmessages: + msg24
2008-05-30 19:31:32zookosetmessages: + msg23
2008-05-30 18:31:47zookosetmessages: + msg22
2008-05-30 18:30:59zookosetstatus: unread -> chatting
messages: + msg21
2008-05-30 18:29:21zookocreate