Re: gdbus function call on interface NULL does not work

[Bernhard Schuster <schuster bernhard googlemail com>]

gdbus hides some functionality of the current dbus spec pretty well, and that is not optimal (and also introduces a lot unncessary code to be written by the library user/programmer instead of proven and tested code in glib).

Instead of ignoreing method call messages without interface field by default, the user should register a filter function to discard such messages if desired, not the other way round. After all that is still part of the current spec.

As I already said, I'd be happy to adjust my patches with error-returnal-on-duplicate-member-detection ( https://bugzilla.gnome.org/show_bug.cgi?id=706675 ) if there is a chance of inclusion.

Best

Bernhard Schuster

2013/8/27 Simon McVittie <simon mcvittie collabora co uk>

On 22/08/13 14:54, Bernhard Schuster wrote:
> I created a demo which shows that remote method calls on interface NULL
> do not work with `g_dbus_connection_register_object`. According to
> http://dbus.freedesktop.org/doc/api/html/group__DBusMessage.html#ga6c8a4c5d350c1962b11300cc4dd0c2e2
> the spec says that this is explicitly allowed for method calls.

My opinion as a D-Bus maintainer: sending method calls "to no interface"
is allowed, but a bad idea. Its semantics are "I don't know or care
which interface I'm calling a method on, please pick one arbitrarily"
which doesn't make a whole lot of sense, since the semantics of a method
are only defined by its interface!

The D-Bus protocol spec says:

    A method call message is required to have a MEMBER header field
    indicating the name of the method. Optionally, the message has an
    INTERFACE field giving the interface the method is a part of. In
    the absence of an INTERFACE field, if two interfaces on the same
    object have a method with the same name, it is undefined which of
    the two methods will be invoked. Implementations may also choose to
    return an error in this ambiguous case.

The spec also says

    However, if a method name is unique implementations must not
    require an interface field

but that doesn't seem very well thought-out, and I'd be tempted to
delete it from the spec. For instance, messages with no interface on the
system bus will usually be shot down by security restrictions, since the
system bus has a default-deny policy and the "firewall" rules that allow
messages through will typically only match particular interfaces.
Allowing messages with an unspecified interface to match a rule with a
particular interface would be a security flaw, because the dbus-daemon
can't know how a service will interpret such a message.

I think it's fine that (semi-)high-level APIs like
g_dbus_connection_call() don't allow omitting the interface - it's a bad
idea, and IMO the spec should have declared it to be undefined behaviour.

If for some reason you really, really need to send a message with "no
interface", then I have two suggestions:

* use lower-level API that doesn't protect you from shooting yourself
  in the foot - g_dbus_message_new_method_call() and the
  g_dbus_connection_send_message_with_reply() family
* redesign your D-Bus API so you don't need to do that

Regards,
    S

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list