dbus example - on_name_lost intermediately after on_name_acquired

I was able to work with dbus as client, but if I compile https://github.com/bratsche/glib/blob/master/gio/tests/gdbus-example-server.c on_name_acquired callback is called and intermediately after on_name_lost callback is called. The only changes that I made is that I use G_BUS_TYPE_SYSTEM instead of G_BUS_TYPE_SESSION

I only guess that this is some authentication issue.

Solution

Unlike the session bus, the system bus has a security policy which prevents arbitrary processes from claiming arbitrary well-known names on the bus. You need to install a configuration file for the system bus to allow your service to own a name:

Rules with the own or own_prefix attribute are checked when a connection attempts to own a well-known bus names. As a special case, own="*" matches any well-known bus name. The well-known session bus normally allows any connection to own any name, while the well-known system bus normally does not allow any connection to own any name, except where allowed by further configuration. System services that will own a name must install configuration that allows them to do so, usually via rules of the form <policy user="some-system-user"><allow own="…"/></policy>.

This means installing a configuration file like the following in /usr/share/dbus-1/system.d/org.mydomain.MyService1.conf:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE busconfig PUBLIC
 "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
  <!-- Only my-service-user can own the service -->
  <policy user="my-service-user">
    <allow own="org.mydomain.MyService1"/>
  </policy>

  <!-- Anyone can send messages to the service -->
  <policy context="default">
    <allow send_destination="org.mydomain.MyService1"/>
  </policy>
</busconfig>

You must then run your service’s process as the my-service-user user.

The D-Bus API design tutorial section on security policies is relevant reading.