Re: [PATCH BlueZ v3 06/15] gdbus: Implement DBus.Properties.Set method

[Marcel Holtmann <marcel@holtmann.org>]

Hi Luiz,

> >> >> Contrary to Get() and GetAll(), Set is asynchronous so we pass on the
> >> >> DBusMessage so user is able to create the response. It's the only use of
> >> >> this parameter.
> >> >> ---
> >> >>  gdbus/gdbus.h  |  7 +++++++
> >> >>  gdbus/object.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
> >> >>  2 files changed, 64 insertions(+), 2 deletions(-)
> >> >>
> >> >> diff --git a/gdbus/gdbus.h b/gdbus/gdbus.h
> >> >> index b2e78c4..3e4aa16 100644
> >> >> --- a/gdbus/gdbus.h
> >> >> +++ b/gdbus/gdbus.h
> >> >> @@ -31,6 +31,8 @@ extern "C" {
> >> >>  #include <dbus/dbus.h>
> >> >>  #include <glib.h>
> >> >>
> >> >> +typedef enum GDBusPropertySetReturn GDBusPropertySetReturn;
> >> >> +
> >> >>  typedef enum GDBusMethodFlags GDBusMethodFlags;
> >> >>  typedef enum GDBusSignalFlags GDBusSignalFlags;
> >> >>  typedef enum GDBusPropertyFlags GDBusPropertyFlags;
> >> >> @@ -69,6 +71,10 @@ typedef DBusMessage * (* GDBusMethodFunction) (DBusConnection *connection,
> >> >>  typedef gboolean (*GDBusPropertyGetter)(const GDBusPropertyTable *property,
> >> >>                                       DBusMessageIter *iter, void *data);
> >> >>
> >> >> +typedef DBusMessage *(*GDBusPropertySetter)(const GDBusPropertyTable *property,
> >> >> +                                     DBusMessageIter *value,
> >> >> +                                     DBusMessage *msg, void *data);
> >> >> +
> >> >
> >> > I am not really happy with this. We just need a unique handle here since
> >> > the return value is either success or an error. I rather don't send
> >> > messages around for no other reason to create the error.
> >> >
> >> > Inside the authorization code I am using GDBusPendingReply as unique
> >> > token. What about using the same approach?
> >>
> >> It would be perfect, but Im afraid sometimes the properties can have
> >> restriction on which sender can set them, so perhaps we need to add
> >> the name of the sender as parameter in addiction to just the handle?
> >
> > that should be done through the same security handling we have for the
> > method calls. Don't try to invent something new.
> 
> Im afraid you will have to go in detail what you want here, the
> security table seems to be meant for checking privileges in a method
> level while we can probably extend it for properties and have
> privileges also in the properties table, but the security table seems
> to be global not per interface.

you can specify unique integer identifiers as security label to each
method. We could extend that to each property. The security label is
used to pick which security callback to call.

Regards

Marcel