<div dir="ltr">Thanks, this is very helpful. <div class="gmail_extra"> <div class="gmail_quote">2018-04-12 14:55 GMT+03:00 Simon McVittie <<a href="mailto:smcv@collabora.com" target="_blank">smcv@collabora.com</a>>: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, 11 Apr 2018 at 16:36:43 +0100, Simon McVittie wrote: > On Wed, 11 Apr 2018 at 17:44:58 +0300, Oleg Kuznecov wrote: > > I have a problem: after dbus upgrade from 1.10.6 to 1.12.6, dbus-monitor > > stopped monitoring method calls if try to monitor remote mashine via TCP/IP. > > Displays only signals. > > Never use D-Bus remotely via TCP. It has no network-level security, > making it vulnerable to eavesdropping and unauthorized access. One thing for which people sometimes (ab)use D-Bus over TCP is this scenario: * some service and some client run on an embedded device * debugging the client on the embedded device is inconvenient * a developer wants to run a local build of the client on their workstation and connect it to the service on their embedded device Using <listen> or --listen to make the dbus-daemon listen on TCP for this purpose should be considered dangerous. The correct way to do this is to set up a tunnel using ssh, socat or a similar relaying tool, which makes it explicit that the security (or lack of security) of this relaying is entirely the developer's responsibility. Since version 1.5.12, dbus has supported a unixexec: transport which is very convenient for this: <<a href="https://bugs.freedesktop.org/show_bug.cgi?id=35230" rel="noreferrer" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=35230</a>>. systemd provides a tool, systemd-stdio-bridge, designed to be used as a unixexec relay. For example, you can connect a client on the workstation to the dbus-daemon on the embedded device like this: dbus-monitor --address "unixexec:path=ssh,argv1=root%40embedded-device,argv2=systemd-stdio-bridge" or by passing that address to APIs like g_dbus_connection_new_for_address() or dbus_connection_open_private(). You can also make a client process connect to the embedded device's system bus whenever its own system bus is requested, by setting the DBUS_SYSTEM_BUS_ADDRESS environment variable. When connecting like this, the client will be acting with the privileges of whatever user ran the systemd-stdio-bridge process, for example root in my dbus-monitor example above (because I used root@embedded-device as the argument to ssh). Note that like all D-Bus addresses, special characters such as @ in the parameters of unixexec: addresses must be escaped in the same way you would for HTTP (%xx). For example, unixexec:path=ssh,argv1=root%40embedded-device,argv2=systemd-stdio-bridge runs the equivalent of the shell command-line 'ssh root@embedded-device systemd-stdio-bridge'. <div class="HOEnZb"><div class="h5"> smcv _______________________________________________ dbus mailing list <a href="mailto:dbus@lists.freedesktop.org">dbus@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/dbus" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/dbus</a> </div></div></blockquote></div> </div></div>