Skip to content
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

Jump to bottom

multiprocessing.connection.Listener fails to close with null byte in AF_UNIX socket name. #84031

Closed
nmichaels mannequin opened this issue Mar 4, 2020 · 5 comments
Closed

multiprocessing.connection.Listener fails to close with null byte in AF_UNIX socket name. #84031

nmichaels mannequin opened this issue Mar 4, 2020 · 5 comments
Labels
3.7 (EOL) end of life 3.8 only security fixes 3.9 only security fixes stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@nmichaels
Copy link
Mannequin

nmichaels mannequin commented Mar 4, 2020

BPO 39850
Nosy @pitrou, @pablogsal
PRs
  • bpo-39850: Add support for abstract sockets in multiprocessing #18866
  • [3.8] bpo-39850: Add support for abstract sockets in multiprocessing (GH-18866) #18876
  • [3.7]bpo-39850: Add support for abstract sockets in multiprocessing (GH-18866) #18877
    		•

    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:

    assignee = None
closed_at = <Date 2020-03-09.14:48:23.277>
created_at = <Date 2020-03-04.16:12:51.698>
labels = ['3.7', '3.8', 'type-bug', 'library', '3.9']
title = 'multiprocessing.connection.Listener fails to close with null byte in AF_UNIX socket name.'
updated_at = <Date 2020-03-09.14:48:23.277>
user = 'https://bugs.python.org/nmichaels'

    bugs.python.org fields:

    activity = <Date 2020-03-09.14:48:23.277>
actor = 'pablogsal'
assignee = 'none'
closed = True
closed_date = <Date 2020-03-09.14:48:23.277>
closer = 'pablogsal'
components = ['Library (Lib)']
creation = <Date 2020-03-04.16:12:51.698>
creator = 'nmichaels'
dependencies = []
files = []
hgrepos = []
issue_num = 39850
keywords = ['patch']
message_count = 4.0
messages = ['363357', '363730', '363737', '363738']
nosy_count = 3.0
nosy_names = ['pitrou', 'nmichaels', 'pablogsal']
pr_nums = ['18866', '18876', '18877']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue39850'
versions = ['Python 3.7', 'Python 3.8', 'Python 3.9']
    @nmichaels nmichaels mannequin added type-crash A hard crash of the interpreter, possibly with a core dump stdlib Python modules in the Lib dir labels Mar 4, 2020
    @nmichaels
    Copy link
    Mannequin Author

    nmichaels mannequin commented Mar 4, 2020 

    >>> 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.

    @pitrou pitrou added 3.7 (EOL) end of life 3.8 only security fixes 3.9 only security fixes type-bug An unexpected behavior, bug, or error and removed type-crash A hard crash of the interpreter, possibly with a core dump labels Mar 8, 2020
    @pablogsal
    Copy link
    Member

    New changeset 6012f30 by Pablo Galindo in branch 'master':
    bpo-39850: Add support for abstract sockets in multiprocessing (GH-18866)
    6012f30

    @pablogsal
    Copy link
    Member

    New changeset 2235e04 by Pablo Galindo in branch '3.7':
    [3.7] bpo-39850: Add support for abstract sockets in multiprocessing (GH-18866) (GH-18877)
    2235e04

    @pablogsal
    Copy link
    Member

    New changeset 3ede1bc by Pablo Galindo in branch '3.8':
    [3.8] bpo-39850: Add support for abstract sockets in multiprocessing (GH-18866) (GH-18876)
    3ede1bc

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    This was referenced Oct 20, 2022
    Closed
    Merged
    @gpshead
    Copy link
    Member

    gpshead commented Oct 20, 2022

    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

    Yhg1s pushed a commit that referenced this issue Oct 20, 2022
    @gpshead
    gh-97514: Don't use Linux abstract sockets for multiprocessing (#98501)
    49f6106 
    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.
    @miss-islington miss-islington mentioned this issue Oct 20, 2022
    Merged
    miss-islington pushed a commit to miss-islington/cpython that referenced this issue Oct 20, 2022
    @gpshead @miss-islington
    pythongh-97514: Don't use Linux abstract sockets for multiprocessing (p…
    bf61665 
    …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>
    @miss-islington miss-islington mentioned this issue Oct 20, 2022
    Merged
    miss-islington pushed a commit to miss-islington/cpython that referenced this issue Oct 20, 2022
    @gpshead @miss-islington
    pythongh-97514: Don't use Linux abstract sockets for multiprocessing (p…
    e745de3 
    …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>
    @miss-islington miss-islington mentioned this issue Oct 20, 2022
    Merged
    miss-islington pushed a commit to miss-islington/cpython that referenced this issue Oct 20, 2022
    @gpshead @miss-islington
    pythongh-97514: Don't use Linux abstract sockets for multiprocessing (p…
    32b2d32 
    …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>
    miss-islington pushed a commit to miss-islington/cpython that referenced this issue Oct 20, 2022
    @gpshead @miss-islington
    pythongh-97514: Don't use Linux abstract sockets for multiprocessing (p…
    85178d5 
    …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>
    miss-islington added a commit that referenced this issue Oct 20, 2022
    @miss-islington
    [3.10] gh-97514: Don't use Linux abstract sockets for multiprocessing (…
    eae692e 
    …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
    miss-islington added a commit that referenced this issue Oct 20, 2022
    @miss-islington
    [3.11] gh-97514: Don't use Linux abstract sockets for multiprocessing (…
    4686d77 
    …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
    pablogsal pushed a commit that referenced this issue Oct 22, 2022
    @miss-islington @pablogsal
    [3.11] gh-97514: Don't use Linux abstract sockets for multiprocessing (…
    4c0c1e2 
    …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
    ambv pushed a commit that referenced this issue Oct 28, 2022
    @miss-islington @gpshead
    [3.9] gh-97514: Don't use Linux abstract sockets for multiprocessing (G…
    b43496c 
    …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>
    frenzymadness pushed a commit to fedora-python/cpython that referenced this issue Nov 9, 2022
    @miss-islington @frenzymadness
    00391: Don't use Linux abstract sockets for multiprocessing
    c21974a 
    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
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees
    No one assigned
    Labels
    3.7 (EOL) end of life 3.8 only security fixes 3.9 only security fixes stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    3 participants
    @gpshead @pitrou @pablogsal