GNOME Bugzilla – Bug 647602
Cannot connect to remote message bus via TCP
Last modified: 2011-04-14 12:57:17 UTC
Created attachment 185830 [details] gdbus output Cannot connect to a remote message bus via TCP with following call: connection = g_dbus_connection_new_for_address_sync ( "tcp:host=localhost,port=8080,family=ipv4", G_DBUS_CONNECTION_FLAGS_MESSAGE_BUS_CONNECTION | G_DBUS_CONNECTION_FLAGS_AUTHENTICATION_CLIENT, NULL, NULL, &temp_error ); Returns error: WaitingForData: unexpected response 'REJECTED EXTERNAL DBUS_COOKIE_SHA1 ANONYMOUS. The following yields identical behavior: G_DBUS_DEBUG="all" DBUS_SESSION_BUS_ADDRESS="tcp:host=localhost,port=8080,family=ipv4" gdbus introspect --session --dest org.freedesktop.DBus --object-path / &> gdbus.log See attachment for output. Can successfully connect to remote message bus using: dbus-monitor --address "tcp:host=localhost,port=8080,family=ipv4" In these cases, the remote message bus is: dbus-daemon-proxy --system
Comment on attachment 185830 [details] gdbus output (Please always use text/plain for textual attachments so it's easier to view in the browser.)
> GDBus-debug:Address: Returning address `tcp:host=localhost,port=8080,family=ipv4' for bus type `session' > GDBus-debug:Auth: CLIENT: initiating > GDBus-debug:Auth: CLIENT: didn't send any credentials > GDBus-debug:Auth: CLIENT: writing `AUTH\r\n' > GDBus-debug:Auth: CLIENT: WaitingForReject > GDBus-debug:Auth: CLIENT: WaitingForReject, read 'REJECTED EXTERNAL DBUS_COOKIE_SHA1 ANONYMOUS' > GDBus-debug:Auth: CLIENT: Trying to choose mechanism > GDBus-debug:Auth: CLIENT: Trying mechanism `EXTERNAL' > GDBus-debug:Auth: CLIENT: Mechanism `EXTERNAL' says it is not supported > GDBus-debug:Auth: CLIENT: Trying to choose mechanism > GDBus-debug:Auth: CLIENT: Trying mechanism `DBUS_COOKIE_SHA1' > GDBus-debug:Auth: CLIENT: writing `AUTH DBUS_COOKIE_SHA1 31303030\r\n' > GDBus-debug:Auth: CLIENT: WaitingForData > GDBus-debug:Auth: CLIENT: WaitingForData, read=`REJECTED EXTERNAL DBUS_COOKIE_SHA1 ANONYMOUS' > GDBus-debug:Auth: CLIENT: Done, authenticated=0 > Error connecting: In WaitingForData: unexpected response `REJECTED EXTERNAL DBUS_COOKIE_SHA1 ANONYMOUS' Hmm. The other peer is running on the same machine but what uid is it running as?
> dbus-monitor --address "tcp:host=localhost,port=8080,family=ipv4" Please run this prefixed with 'strace -o log.txt -s2000 ' and attach the log.. thanks.
> dbus-daemon-proxy --system What is this? I've never seen that before.
(In reply to comment #4) > > dbus-daemon-proxy --system > > What is this? I've never seen that before. http://alban.apinc.org/blog/2010/04/01/d-bus-debugging-how-to-use-d-feet-on-n900/ sheds some light... could be why it's not working. I haven't read the dbus-daemon-proxy code - could be it's just relying on some libdbus peculiarity. I don't know.
(In reply to comment #3) > > dbus-monitor --address "tcp:host=localhost,port=8080,family=ipv4" > > Please run this prefixed with 'strace -o log.txt -s2000 ' and attach the log.. > thanks. Need this before we can make forward progress... That said, I think I know what the problem is: GDBus isn't trying the ANONYMOUS authentication method which I think is the only one that is going to work ... in particular, I predict that the strace logs will show us that dbus-monitor is using that authentication method. It should be possible to fix this, I just want to make sure that's the problem...
Created attachment 185850 [details] strace output
(In reply to comment #2) > > GDBus-debug:Address: Returning address `tcp:host=localhost,port=8080,family=ipv4' for bus type `session' > > GDBus-debug:Auth: CLIENT: initiating > > GDBus-debug:Auth: CLIENT: didn't send any credentials > > GDBus-debug:Auth: CLIENT: writing `AUTH\r\n' > > GDBus-debug:Auth: CLIENT: WaitingForReject > > GDBus-debug:Auth: CLIENT: WaitingForReject, read 'REJECTED EXTERNAL DBUS_COOKIE_SHA1 ANONYMOUS' > > GDBus-debug:Auth: CLIENT: Trying to choose mechanism > > GDBus-debug:Auth: CLIENT: Trying mechanism `EXTERNAL' > > GDBus-debug:Auth: CLIENT: Mechanism `EXTERNAL' says it is not supported > > GDBus-debug:Auth: CLIENT: Trying to choose mechanism > > GDBus-debug:Auth: CLIENT: Trying mechanism `DBUS_COOKIE_SHA1' > > GDBus-debug:Auth: CLIENT: writing `AUTH DBUS_COOKIE_SHA1 31303030\r\n' > > GDBus-debug:Auth: CLIENT: WaitingForData > > GDBus-debug:Auth: CLIENT: WaitingForData, read=`REJECTED EXTERNAL DBUS_COOKIE_SHA1 ANONYMOUS' > > GDBus-debug:Auth: CLIENT: Done, authenticated=0 > > Error connecting: In WaitingForData: unexpected response `REJECTED EXTERNAL DBUS_COOKIE_SHA1 ANONYMOUS' > > Hmm. The other peer is running on the same machine but what uid is it running > as? The UIDs are the same.
(In reply to comment #7) > Created an attachment (id=185850) [details] > strace output Yah, here's the relevant bit: > write(4, "\0", 1) = 1 > write(4, "AUTH EXTERNAL 31303030\r\n", 24) = 24 > poll([{fd=4, events=POLLIN}], 1, -1) = 1 ([{fd=4, revents=POLLIN}]) > read(4, "REJECTED EXTERNAL DBUS_COOKIE_SHA1 ANONYMOUS\r\n", 2048) = 46 > geteuid32() = 1000 > poll([{fd=4, events=POLLOUT}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}]) > write(4, "AUTH DBUS_COOKIE_SHA1 31303030\r\n", 32) = 32 > poll([{fd=4, events=POLLIN}], 1, -1) = 1 ([{fd=4, revents=POLLIN}]) > read(4, "REJECTED EXTERNAL DBUS_COOKIE_SHA1 ANONYMOUS\r\n", 2048) = 46 > poll([{fd=4, events=POLLOUT}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}]) > write(4, "AUTH ANONYMOUS 6c69626462757320312e322e3136\r\n", 45) = 45 > poll([{fd=4, events=POLLIN}], 1, -1) = 1 ([{fd=4, revents=POLLIN}]) > read(4, "OK e276c737586418a11193c50f4da5670b\r\n", 2048) = 37 > poll([{fd=4, events=POLLOUT}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}]) > write(4, "BEGIN\r\n", 7) = 7 confirming what I suspected in comment 6. Should be easy to fix, stay tuned...
I'm curious why the other peer rejected DBUS_COOKIE_SHA1 authentication. It works fine on my box. Perhaps you are playing games with ssh tunnels as suggested by this comment http://alban.apinc.org/blog/2010/04/01/d-bus-debugging-how-to-use-d-feet-on-n900/#comment-4684 If so, please note that tunneling hacks like this are not going to work very well since some authentication problems like e.g. DBUS_COOKIE_SHA1 rely on a shared and secured home directory. Which is probably why the authentication conversation falls back to the ANONYMOUS method (which the other peer actually offers). Either way, I guess I can't complain since it exposed a bug in GDBus :-). The fix is here http://git.gnome.org/browse/glib/commit/?id=e38ef14e8b8d2fed909d92514b665bb8c3c99e6c Please let me know if it works. Thanks.
I'm not sure why DBUS_COOKIE_SHA1 authentication was rejected either. I was not performing any tunneling. In any case, you've fixed the problem. Thanks David.
(In reply to comment #11) > I'm not sure why DBUS_COOKIE_SHA1 authentication was rejected either. I was not > performing any tunneling. OK. It can a number of other things (such as wrong permissions on the ~/.dbus-keyrings directory - that's how I "forced" DBUS_COOKIE_SHA1 to fail) - but it's not really important why. > In any case, you've fixed the problem. Thanks David. Great, thanks for testing!