"dbus-monitor --system" stopped monitoring method calls remotely

[Oleg Kuznecov]

Thanks, this is very helpful.

2018-04-12 14:55 GMT+03:00 Simon McVittie <smcv at collabora.com>:

> 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:
> <https://bugs.freedesktop.org/show_bug.cgi?id=35230>. 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 at 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 at embedded-device systemd-stdio-bridge'.
>
>     smcv
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dbus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dbus/attachments/20180412/6bab3d58/attachment.html>