Interceptor for org.freedesktop.DBus.Properties.Set
patrick at stwcx.xyz
Wed Sep 14 05:08:25 AEST 2016
On Tue, Sep 13, 2016 at 02:11:04PM +0530, vishwa wrote:
> /org/openbmc/settings/host0 provides the dbus properties that are
> settable via org.freedesktop.DBus.properties.Set.
> The properties are treated as user settings and are consumed by
> respective daemons by having a signal handler registered for
> PropertyChanged method.
> The challenge at the hand is "How to make sure the users that set the
> property are choosing a valid value".
> Since its set by org.freedesktop.DBus.Properties.Set, the ideal way
> would be to register a callback that would validate the user input based
> on custom algo and then only would let the .Set continue.
> Without an interceptor, the user settings may be as junk as "abcdef" and
> the *settings damon* can only react to that change and can put the
> previous value back into it post verification.
> I did a lot of search on ways to register an interceptor and did not see
> one. I then asked in #dbus and they told me that there is no way to
> intercept that.
The way to do it entirely depends on the DBus binding in use. I'm not
sure why people in #dbus would tell you it cannot be done.
The systemd/sd-bus vtable entry for a "writable property" allows a
property to be managed directly by systemd (pass property by pointer) or
via indirect get/set methods:
If you look through the systemd repository you will find some
SD_BUS_WRITABLE_PROPERTY calls where the get/set methods are used and
those can clearly cause a Dbus.Error instead of returning success.
phosphor-settingsd is currently using a pyphosphor wrapper around the
python dbus bindings. Here we implement the
I think you could enhance this to call a set/get function, if present, for
specific properties. Those can throw an exception which will turn into
> So the solution what I have at the moment is to
> 1) Disable the property set via freedesktop
> 2) Introduce a custom Setter "org.openbmc.Settings.Host.Set" which can
> do the job of validating the inputs also.
> Please let me know if there are better approaches.
> Vishwanatha Subbanna.
> openbmc mailing list
> openbmc at lists.ozlabs.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature
More information about the openbmc