[issue45564] shutil.rmtree and os.walk are implemented using recursion, fail on deep hierarchies

2021-10-21 Thread Alexander Patrakov 


New submission from Alexander Patrakov :

It is possible to create deep directory hierarchies that cannot be removed via 
shutil.rmtree or walked via os.walk, because these functions exceed the 
interpreter recursion limit. This may have security implications for web 
services (e.g. various webdisks) that have to clean up user-created mess or 
walk through it.

[aep@aep-haswell ~]$ mkdir /tmp/badstuff
[aep@aep-haswell ~]$ cd /tmp/badstuff
[aep@aep-haswell badstuff]$ for x in `seq 2048` ; do mkdir $x ; cd $x ; done
[aep@aep-haswell 103]$ cd
[aep@aep-haswell ~]$ python
Python 3.9.7 (default, Oct 10 2021, 15:13:22) 
[GCC 11.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import shutil
>>> shutil.rmtree('/tmp/badstuff')
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.9/shutil.py", line 726, in rmtree
_rmtree_safe_fd(fd, path, onerror)
  File "/usr/lib/python3.9/shutil.py", line 663, in _rmtree_safe_fd
_rmtree_safe_fd(dirfd, fullname, onerror)
  File "/usr/lib/python3.9/shutil.py", line 663, in _rmtree_safe_fd
_rmtree_safe_fd(dirfd, fullname, onerror)
  File "/usr/lib/python3.9/shutil.py", line 663, in _rmtree_safe_fd
_rmtree_safe_fd(dirfd, fullname, onerror)
  [Previous line repeated 992 more times]
  File "/usr/lib/python3.9/shutil.py", line 642, in _rmtree_safe_fd
fullname = os.path.join(path, entry.name)
  File "/usr/lib/python3.9/posixpath.py", line 77, in join
sep = _get_sep(a)
  File "/usr/lib/python3.9/posixpath.py", line 42, in _get_sep
if isinstance(path, bytes):
RecursionError: maximum recursion depth exceeded while calling a Python object
>>> import os
>>> list(os.walk('/tmp/badstuff'))
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.9/os.py", line 418, in _walk
yield from _walk(new_path, topdown, onerror, followlinks)
  File "/usr/lib/python3.9/os.py", line 418, in _walk
yield from _walk(new_path, topdown, onerror, followlinks)
  File "/usr/lib/python3.9/os.py", line 418, in _walk
yield from _walk(new_path, topdown, onerror, followlinks)
  [Previous line repeated 993 more times]
  File "/usr/lib/python3.9/os.py", line 412, in _walk
new_path = join(top, dirname)
  File "/usr/lib/python3.9/posixpath.py", line 77, in join
sep = _get_sep(a)
  File "/usr/lib/python3.9/posixpath.py", line 42, in _get_sep
if isinstance(path, bytes):
RecursionError: maximum recursion depth exceeded while calling a Python object
>>>

--
components: Library (Lib)
messages: 404687
nosy: Alexander.Patrakov
priority: normal
severity: normal
status: open
title: shutil.rmtree and os.walk are implemented using recursion, fail on deep 
hierarchies
type: crash
versions: Python 3.9

___
Python tracker 
<https://bugs.python.org/issue45564>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22224] docs.python.org is prone to political blocking in Russia

2014-08-18 Thread Alexander Patrakov 

New submission from Alexander Patrakov:

I could not access http://docs.python.org/ from work today. Upon investigation, 
it appears that the ISP has blocked all sites on the IP address 185.31.17.175, 
because of the court order unrelated to docs.python.org. Many other ISPs in 
Russia also don't know any methods of site blocking except by IP address.

Even if the bad site removes the offending materials, the situation is doomed 
to repeat itself in the future.

To avoid this, please obtain an IPv4 or IPv6 address for docs.python.org that 
is not shared with any site not controlled by PSF.

--
assignee: docs@python
components: Documentation
messages: 225487
nosy: Alexander.Patrakov, docs@python
priority: normal
severity: normal
status: open
title: docs.python.org is prone to political blocking in Russia
type: behavior

___
Python tracker 
<http://bugs.python.org/issue4>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22224] docs.python.org is prone to political blocking in Russia

2014-08-20 Thread Alexander Patrakov 

Alexander Patrakov added the comment:

The site is now accessible. But this case is going to repeat itself.

--

___
Python tracker 
<http://bugs.python.org/issue4>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22249] Possibly incorrect example is given for socket.getaddrinfo()

2014-08-22 Thread Alexander Patrakov 

New submission from Alexander Patrakov:

See the example at 
https://docs.python.org/2/library/socket.html#socket.getaddrinfo

>>> socket.getaddrinfo("www.python.org", 80, 0, 0, socket.SOL_TCP)

As I am primarily a C programmer, it is quite surprising for me to see a SOL_* 
being passed into the proto argument. I thought that SOL_* is only for 
setsockopt(), and IPPROTO_* would be suitable. Yes, for TCP and UDP the SOL_* 
and IPPROTO_* constants are the same, but see e.g. 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms737530%28v=vs.85%29.aspx
 which specifically points out that IPPROTO_* constants as acceptable values.

--
assignee: docs@python
components: Documentation
messages: 225659
nosy: Alexander.Patrakov, docs@python
priority: normal
severity: normal
status: open
title: Possibly incorrect example is given for socket.getaddrinfo()
type: behavior
versions: Python 2.7

___
Python tracker 
<http://bugs.python.org/issue22249>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com