Native Go bindings for D-Bus

It only compiles on linux, since

syscall.UnixCredentials

is in an _linux.go file in the standard go library.

http://golang.org/src/pkg/syscall/sockcmsg_linux.go?s=367:408#L4

On Fedora 33, building and running any of the examples e.g. list-names.go will fail with

$ ./listnames
Failed to connect to session bus: dbus: authentication failed

There's a usable session bus address

$ echo $DBUS_SESSION_BUS_ADDRESS
unix:path=/run/user/1000/bus

and command-line d-bus operations work

$ dbus-send --session --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames
method return time=1629168407.533841 sender=org.freedesktop.DBus -> destination=:1.10056 serial=4294967295 reply_serial=2
   array [
      string "org.freedesktop.DBus"
      .....

so the bus is usable.

SELinux is in permissive mode (unfortunately, due to unrelated issues) so it's not SELinux related.

I don't see any relevant output in dbus-monitor --session when I attempt to auth while it's running.

It's unclear why this is happening. I'll look into it, but wanted to file this now so others with a similar issue can find it.

Exported methods can receive the sender of the message by specifying an argument of type dbus.Sender. Upon calling, this argument will be set to the sender of the message. Any dbus.Sender arguments are not part of the dbus method signature.

An empty struct will cause bus connection closed

type of '()' can be show in d-feet. And dbus spec doesn't specify whether an struct can be an empty.

It would be nice if the sender could be passed to a method call if a user wants to. A new type Sender string could be introduced which when found in a method signature would receive the sender of the message.

It does not seem possible to read the properties of com.ubuntu.Upstart0_6.Instance (com.ubuntu.Upstart0_6.Instance.name, com.ubuntu.Upstart0_6.Instance.state, etc.), as per: http://upstart.ubuntu.com/wiki/DBusInterface, only execute methods associated to that object. Not sure if there is a supported mechanism, for example, to read the PID of a particular instance.

Hi

I am trying to call GetManagedObjects on the org.freedesktop.DBus.ObjectManager interface of org.freedesktop.UDisks2.

According to http://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-objectmanager

The signature is:

    org.freedesktop.DBus.ObjectManager.GetManagedObjects (out DICT<OBJPATH,DICT<STRING,DICT<STRING,VARIANT>>> objpath_interfaces_and_properties);

udisk := conn.Object("org.freedesktop.UDisks2", "/org/freedesktop/UDisks2")

...

ret := make(map[dbus.ObjectPath]map[string]dbus.Variant)
err = udisk.Call("org.freedesktop.DBus.ObjectManager.GetManagedObjects", 0).Store(ret)

if err != nil {
  panic(err)
}

results in

panic: reflect: call of reflect.Value.Elem on map Value

What would be the correct way to call this method?

The "standard" way to launch dbus on OS X is through launchd which is responsible for allocating a unix domain socket and then passing it to dbus. This patch splits out a platform specific method to obtain the session bus if DBUS_SESSION_BUS_ADDRESS is not set. On OS X launchctl is queried while on other platforms dbus-launch is used as before.

The "standard" way to launch dbus on OS X is through launchd which is responsible for allocating a unix domain socket and then passing it to dbus. This patch splits out a platform specific method to obtain the session bus if DBUS_SESSION_BUS_ADDRESS is not set. On OS X launchctl is queried while on other platforms dbus-launch is used as before.

The "standard" way to launch dbus on OS X is through launchd which is responsible for allocating a unix domain socket and then passing it to dbus. This patch splits out a platform specific method to obtain the session bus if DBUS_SESSION_BUS_ADDRESS is not set. On OS X launchctl is queried while on other platforms dbus-launch is used as before.

I'm trying to use go.dbus on OS X which doesn't support syscall.Ucred. However, I found that SendNullByte is currently not used anywhere. Can it be removed altogether?

See issue #68 for details.

This pull request incorporates the proposed fix for #68 as seen in the commit message for 9c4d13f, as well as an option to trace the protocol exchange during authentication and a small README change.

Note that this changes the public interface dbus.Auth to allow mechanism implementations to accept and respond with DATA payloads of zero or more elements, instead of the fixed single-element payloads the interface baked in previously.

This is a breaking API change for external implementations of dbus.Auth but doesn't change any other public API.

In #33 it was decided to not pin the Ucred calls to Linux only. However this would have been the right thing to do, even for BSDs.

See these for reference:

• https://github.com/golang/sys/blob/master/unix/sockcmsg_linux.go
• https://github.com/golang/sys/blob/master/unix/sockcmsg_unix.go

conn.Close() closes the transport corresponding to the connection. After that inWorker() will see EOF and will try to close the connection again. This then leads to attempt to close closed channel.

$ cat bug.go
package main

import (
        "time"

        dbus "github.com/guelfey/go.dbus"
)

func main() {
        conn, _ := dbus.SessionBusPrivate()
        conn.Auth(nil)
        conn.Hello()
        conn.RequestName("com.github.guelfey.Demo", dbus.NameFlagDoNotQueue)
        conn.Close()
        time.Sleep(1 * time.Second)
}
$ go run bug.go
panic: close of closed channel

goroutine 6 [running]:
github.com/guelfey/go%2edbus.(*Conn).Close(0x4c2080010e0, 0x0, 0x0)
        github.com/guelfey/go.dbus/conn.go:178 +0x62
github.com/guelfey/go%2edbus.(*Conn).inWorker(0x4c2080010e0)
        github.com/guelfey/go.dbus/conn.go:334 +0x10be
created by github.com/guelfey/go%2edbus.(*Conn).Auth
        github.com/guelfey/go.dbus/auth.go:120 +0xecd