aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/Lib/multiprocessing/reduction.py
diff options
context:
space:
mode:
authorGregory P. Smith <greg@krypto.org>2024-11-20 08:18:58 -0800
committerGitHub <noreply@github.com>2024-11-20 08:18:58 -0800
commit7191b7662efcd79f2f19821c9b9fa2155df6f698 (patch)
treed8dd04783fd168e3c0f8f7256420523ae759c3b8 /Lib/multiprocessing/reduction.py
parent48c50ff1a22f086c302c52a70eb9912d76c66f91 (diff)
downloadcpython-7191b7662efcd79f2f19821c9b9fa2155df6f698.tar.gz
cpython-7191b7662efcd79f2f19821c9b9fa2155df6f698.zip
gh-97514: Authenticate the forkserver control socket. (GH-99309)
This adds authentication to the forkserver control socket. In the past only filesystem permissions protected this socket from code injection into the forkserver process by limiting access to the same UID, which didn't exist when Linux abstract namespace sockets were used (see issue) meaning that any process in the same system network namespace could inject code. We've since stopped using abstract namespace sockets by default, but protecting our control sockets regardless of type is a good idea. This reuses the HMAC based shared key auth already used by `multiprocessing.connection` sockets for other purposes. Doing this is useful so that filesystem permissions are not relied upon and trust isn't implied by default between all processes running as the same UID with access to the unix socket. ### pyperformance benchmarks No significant changes. Including `concurrent_imap` which exercises `multiprocessing.Pool.imap` in that suite. ### Microbenchmarks This does _slightly_ slow down forkserver use. How much so appears to depend on the platform. Modern platforms and simple platforms are less impacted. This PR adds additional IPC round trips to the control socket to tell forkserver to spawn a new process. Systems with potentially high latency IPC are naturally impacted more. Typically a 1-4% slowdown on a very targeted process creation microbenchmark, with a worst case overloaded system slowdown of 20%. No evidence that these slowdowns appear in practical sense. See the PR for details.
Diffstat (limited to 'Lib/multiprocessing/reduction.py')
-rw-r--r--Lib/multiprocessing/reduction.py12
1 files changed, 6 insertions, 6 deletions
diff --git a/Lib/multiprocessing/reduction.py b/Lib/multiprocessing/reduction.py
index 5593f0682f7..fcccd3eef86 100644
--- a/Lib/multiprocessing/reduction.py
+++ b/Lib/multiprocessing/reduction.py
@@ -139,15 +139,12 @@ else:
__all__ += ['DupFd', 'sendfds', 'recvfds']
import array
- # On MacOSX we should acknowledge receipt of fds -- see Issue14669
- ACKNOWLEDGE = sys.platform == 'darwin'
-
def sendfds(sock, fds):
'''Send an array of fds over an AF_UNIX socket.'''
fds = array.array('i', fds)
msg = bytes([len(fds) % 256])
sock.sendmsg([msg], [(socket.SOL_SOCKET, socket.SCM_RIGHTS, fds)])
- if ACKNOWLEDGE and sock.recv(1) != b'A':
+ if sock.recv(1) != b'A':
raise RuntimeError('did not receive acknowledgement of fd')
def recvfds(sock, size):
@@ -158,8 +155,11 @@ else:
if not msg and not ancdata:
raise EOFError
try:
- if ACKNOWLEDGE:
- sock.send(b'A')
+ # We send/recv an Ack byte after the fds to work around an old
+ # macOS bug; it isn't clear if this is still required but it
+ # makes unit testing fd sending easier.
+ # See: https://github.com/python/cpython/issues/58874
+ sock.send(b'A') # Acknowledge
if len(ancdata) != 1:
raise RuntimeError('received %d items of ancdata' %
len(ancdata))