bpo-39850: Add support for abstract sockets in multiprocessing #18866

pablogsal · 2020-03-09T01:45:24Z

https://bugs.python.org/issue39850

pitrou

LGTM, just a nit.

Lib/multiprocessing/util.py

pitrou · 2020-03-09T09:34:41Z

By the way, I don't think this can be backported since it's a behaviour change. If we want to fix support for abstract sockets on 3.7-3.8 we'll need a different patch.

Lib/multiprocessing/util.py

pablogsal · 2020-03-09T10:06:02Z

@pitrou Would you like me to split this PR in two (one with the fix 'per se' and the other with the new default)?

Another possibility is that I create manually the backports, removing the new behaviour in the process.

Lib/test/_test_multiprocessing.py

pitrou · 2020-03-09T10:08:00Z

@pablogsal As is the most convenient for you.

Co-Authored-By: Victor Stinner <vstinner@python.org>

Lib/multiprocessing/managers.py

Lib/multiprocessing/util.py

pablogsal · 2020-03-09T13:21:27Z

LGTM. Thanks for all updates I asked for ;-)

Always happy to do them! Thanks for the review :)

…ythonGH-18866) (cherry picked from commit 6012f30) Co-authored-by: Pablo Galindo <Pablogsal@gmail.com>

…ssing (pythonGH-18866) (cherry picked from commit 6012f30) Co-authored-by: Pablo Galindo <Pablogsal@gmail.com>. (cherry picked from commit 5e217bb) Co-authored-by: Pablo Galindo <Pablogsal@gmail.com>

…H-18866) (GH-18877) (cherry picked from commit 6012f30)

…H-18866) (GH-18876) (cherry picked from commit 6012f30)

AmirHmZz · 2020-04-03T12:24:09Z

So now does windows support AF_UNIX for IPC ?

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>

…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

…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

the-knights-who-say-ni added the CLA signed label Mar 9, 2020

bedevere-bot added the awaiting core review label Mar 9, 2020

pablogsal force-pushed the bpo-39850 branch 2 times, most recently from 4c3361e to 338696b Compare March 9, 2020 01:49

pablogsal requested a review from pitrou March 9, 2020 01:49

pablogsal force-pushed the bpo-39850 branch from 338696b to 1c419a7 Compare March 9, 2020 01:54

pablogsal self-assigned this Mar 9, 2020

pablogsal force-pushed the bpo-39850 branch 5 times, most recently from 4fa7210 to 95575e1 Compare March 9, 2020 02:53

bpo-39850: Add support for abstract sockets in multiprocessing

5153c7e

pablogsal force-pushed the bpo-39850 branch from 95575e1 to 5153c7e Compare March 9, 2020 02:56

pitrou reviewed Mar 9, 2020

View reviewed changes

Lib/multiprocessing/util.py Show resolved Hide resolved