When pickling a proxy object (such as a list) created on a client, an 
exception is thrown. Example attached.

Python 2.6.4 Mac OS X 10.6

p

UPDATE: this example WORKS if you remove "authkey" - so it seems to be a 
problem with authentication.

Confirmed for Python 2.7.1 on Ubuntu.

Problematic are the __reduce__ methods of multiprocessing.process.AuthenticationString and multiprocessing.managers.BaseProxy. Pickling of an authkey in BaseProxy is only done and allowed when Popen.thread_is_spawning() is True. The comments state this is done because of security reasons.

If you pass proxies with multiprocessing after process initialization then no authkey is available after unpickle, a random authkey will be used with results in an digest error. Because of this fallback in case no authkey is available, using None as authkey didn't work in my case.

This bug looks like a design flaw of multiprocessing. If security was really a concern, encryption should be used along with authentication for communication. And passing None as authkey should disable authentication as stated in the documentation and should not use a random authkey.

Disabling the Popen.thread_is_spawning() checks allows passing of proxies. I have done this during runtime by replacing the __reduce__ methods of the affected classes to avoid patching the installed python.

forgot to set version in classification

[Note, due to a bug tracker error now fixed, s couple of comments made to this issue earlier today were dropped.  I'm manually adding them here on behalf of the original submitters.]

At Wed Feb 26 17:05:01 CET 2014, Paul Tunison added the comment:

I can confirm that this is still an issue with python 2.7.5. My method of resolving this locally is similar to xhantu's. I created a sub-class of BaseProxy, overriding the __reduce__ method and injecting the authkey into the appropriate spot in the super method's returned content.

At Wed Feb 26 17:09:49 CET 2014, Dhanannjay Deo added the comment:

Confirmed for python 2.7.3 on ubuntu 12.04 lts. Why this issue is still open after 4 years ?

For reasons we all know unpickling unauthenticated data received over TCP is very risky.  Sending an unencrypted authentication key (as part of a pickle) over TCP would make the authentication useless.

When a proxy is pickled the authkey is deliberately dropped.  When the proxy is unpickled the authkey used for the reconstructed proxy is current_process().authkey.  So you can "fix" the example by setting the current_process().authkey to match the one used by the manager:

import multiprocessing
from multiprocessing import managers
import pickle

class MyManager(managers.SyncManager):
    pass

def client():
    mgr = MyManager(address=("localhost",2288),authkey="12345")
    mgr.connect()
    l = mgr.list()
    multiprocessing.current_process().authkey = "12345"    # <--- HERE
    l = pickle.loads(pickle.dumps(l))

def server():
    mgr = MyManager(address=("",2288),authkey="12345")
    mgr.get_server().serve_forever()

server = multiprocessing.Process(target=server)
client = multiprocessing.Process(target=client)
server.start()
client.start()
client.join()
server.terminate()
server.join()

In practice all processes using the manager should have current_process().authkey set to the same value.

I don't claim that multiprocessing supports distributed computing very well, but as far as I can see, things are working as intended.

Per Richard's post from 1 year ago where he offers both explanation and an example, ultimately concluding that things are working as intended, and because there have been no objections or requests for clarification in the past year, closing this and marking it as not a bug.

nosy: + davin
messages: + msg237796

resolution: not a bug
stage: resolved

messages: + msg212304
versions: - Python 2.6