-
-
Notifications
You must be signed in to change notification settings - Fork 30.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
multiprocessing.connection.Listener fails to close with null byte in AF_UNIX socket name. #84031
Comments
>>> from multiprocessing.connection import Listener
>>> listener = Listener('\0conntest', family='AF_UNIX')
>>> listener.close()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib64/python3.6/multiprocessing/connection.py", line 466, in close
listener.close()
File "/usr/lib64/python3.6/multiprocessing/connection.py", line 604, in close
unlink()
File "/usr/lib64/python3.6/multiprocessing/util.py", line 186, in __call__
res = self._callback(*self._args, **self._kwargs)
ValueError: embedded null byte Linux has a handy feature where if the first byte of a unix domain socket's name is the null character, it won't put it in the filesystem. The socket interface works fine with it, but when SocketListener is wrapped around a socket, it throws this exception. |
Now that it's public... if you are explicitly asking multiprocessing to use Linux abstract sockets in your code you likely have a security problem: #97514 |
Linux abstract sockets are insecure as they lack any form of filesystem permissions so their use allows anyone on the system to inject code into the process. This removes the default preference for abstract sockets in multiprocessing introduced in Python 3.9+ via #18866 while fixing #84031. Explicit use of an abstract socket by a user now generates a RuntimeWarning. If we choose to keep this warning, it should be backported to the 3.7 and 3.8 branches.
…ythonGH-98501) Linux abstract sockets are insecure as they lack any form of filesystem permissions so their use allows anyone on the system to inject code into the process. This removes the default preference for abstract sockets in multiprocessing introduced in Python 3.9+ via python#18866 while fixing python#84031. Explicit use of an abstract socket by a user now generates a RuntimeWarning. If we choose to keep this warning, it should be backported to the 3.7 and 3.8 branches. (cherry picked from commit 49f6106) Co-authored-by: Gregory P. Smith <greg@krypto.org>
…ythonGH-98501) Linux abstract sockets are insecure as they lack any form of filesystem permissions so their use allows anyone on the system to inject code into the process. This removes the default preference for abstract sockets in multiprocessing introduced in Python 3.9+ via python#18866 while fixing python#84031. Explicit use of an abstract socket by a user now generates a RuntimeWarning. If we choose to keep this warning, it should be backported to the 3.7 and 3.8 branches. (cherry picked from commit 49f6106) Co-authored-by: Gregory P. Smith <greg@krypto.org>
…ythonGH-98501) Linux abstract sockets are insecure as they lack any form of filesystem permissions so their use allows anyone on the system to inject code into the process. This removes the default preference for abstract sockets in multiprocessing introduced in Python 3.9+ via python#18866 while fixing python#84031. Explicit use of an abstract socket by a user now generates a RuntimeWarning. If we choose to keep this warning, it should be backported to the 3.7 and 3.8 branches. (cherry picked from commit 49f6106) Co-authored-by: Gregory P. Smith <greg@krypto.org>
…ythonGH-98501) Linux abstract sockets are insecure as they lack any form of filesystem permissions so their use allows anyone on the system to inject code into the process. This removes the default preference for abstract sockets in multiprocessing introduced in Python 3.9+ via python#18866 while fixing python#84031. Explicit use of an abstract socket by a user now generates a RuntimeWarning. If we choose to keep this warning, it should be backported to the 3.7 and 3.8 branches. (cherry picked from commit 49f6106) Co-authored-by: Gregory P. Smith <greg@krypto.org>
…GH-98501) (GH-98503) Linux abstract sockets are insecure as they lack any form of filesystem permissions so their use allows anyone on the system to inject code into the process. This removes the default preference for abstract sockets in multiprocessing introduced in Python 3.9+ via #18866 while fixing #84031. Explicit use of an abstract socket by a user now generates a RuntimeWarning. If we choose to keep this warning, it should be backported to the 3.7 and 3.8 branches. (cherry picked from commit 49f6106) Co-authored-by: Gregory P. Smith <greg@krypto.org> Automerge-Triggered-By: GH:gpshead
…GH-98501) (GH-98502) Linux abstract sockets are insecure as they lack any form of filesystem permissions so their use allows anyone on the system to inject code into the process. This removes the default preference for abstract sockets in multiprocessing introduced in Python 3.9+ via #18866 while fixing #84031. Explicit use of an abstract socket by a user now generates a RuntimeWarning. If we choose to keep this warning, it should be backported to the 3.7 and 3.8 branches. (cherry picked from commit 49f6106) Co-authored-by: Gregory P. Smith <greg@krypto.org> Automerge-Triggered-By: GH:gpshead
…GH-98501) (GH-98502) Linux abstract sockets are insecure as they lack any form of filesystem permissions so their use allows anyone on the system to inject code into the process. This removes the default preference for abstract sockets in multiprocessing introduced in Python 3.9+ via #18866 while fixing #84031. Explicit use of an abstract socket by a user now generates a RuntimeWarning. If we choose to keep this warning, it should be backported to the 3.7 and 3.8 branches. (cherry picked from commit 49f6106) Co-authored-by: Gregory P. Smith <greg@krypto.org> Automerge-Triggered-By: GH:gpshead
…H-98501) (#98504) Linux abstract sockets are insecure as they lack any form of filesystem permissions so their use allows anyone on the system to inject code into the process. This removes the default preference for abstract sockets in multiprocessing introduced in Python 3.9+ via #18866 while fixing #84031. Explicit use of an abstract socket by a user now generates a RuntimeWarning. If we choose to keep this warning, it should be backported to the 3.7 and 3.8 branches. (cherry picked from commit 49f6106) Co-authored-by: Gregory P. Smith <greg@krypto.org>
Linux abstract sockets are insecure as they lack any form of filesystem permissions so their use allows anyone on the system to inject code into the process. This removes the default preference for abstract sockets in multiprocessing introduced in Python 3.9+ via python#18866 while fixing python#84031. Explicit use of an abstract socket by a user now generates a RuntimeWarning. If we choose to keep this warning, it should be backported to the 3.7 and 3.8 branches. (cherry picked from commit 49f6106) Co-authored-by: Gregory P. Smith <greg@krypto.org> Automerge-Triggered-By: GH:gpshead
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: