> The vulnerability goes basically like this: If you tar a file named
> "../../../../../etc/passwd" and then make the admin untar it,
> /etc/passwd gets overwritten.
> Another variety of this bug is a symlink one: if tar contains files like:
> ./-directory -> /etc
> ./-directory/passwd
> th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hi,
once upon a time there was a known vulnerability in tar (CVE-2001-1267,
[1]), and while tar is now long fixed, python's tarfile module is
affected too.
The vulnerability goes basically like this: If you tar a file named
"../../../../../etc/passwd"
On 8/24/07, Hrvoje Nikšić <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-08-23 at 11:57 -0700, Neal Norwitz wrote:
> > > "allow threads" section that runs with the GIL released, file_close
> > > might acquire the GIL and be running in parallel to this code. If
> > > file_close sets f_fp to NULL after t
On Fri, Aug 24, 2007, eSX wrote:
>
> Here is 3 PYs, we found there is a big memory wasting, specially the
> program c.py, we found the memory will increase very soon. any body
> knows why? any RC's problem? thanks
Please post your question to comp.lang.python; python-dev is not a
suitable place fo
hi all,
Here is 3 PYs, we found there is a big memory wasting, specially the program
c.py, we found the memory will increase very soon.
any body knows why? any RC's problem? thanks
--
eSX
class a():
def __init__(self):
fp = open("a_file_lager_1M","rb")
self
On Thu, 2007-08-23 at 11:57 -0700, Neal Norwitz wrote:
> > "allow threads" section that runs with the GIL released, file_close
> > might acquire the GIL and be running in parallel to this code. If
> > file_close sets f_fp to NULL after the "if" condition evaluates, but
> > before the call to _port
