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

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
Labels
3.7 (EOL) end of life 3.8 (EOL) end of life 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 (EOL) end of life 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

    @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
    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 pushed a commit to miss-islington/cpython that referenced this issue Oct 20, 2022
    …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
    …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
    …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
    …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
    …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
    …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
    …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
    …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
    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
    Labels
    3.7 (EOL) end of life 3.8 (EOL) end of life 3.9 only security fixes stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Development

    No branches or pull requests

    3 participants