kdesupport/polkit-qt question
Kevin Krammer
kevin.krammer at gmx.at
Wed Mar 11 20:23:02 GMT 2009
On Wednesday 11 March 2009, Dario Freddi wrote:
> In data mercoledì 11 marzo 2009 20:10:30, Kevin Krammer ha scritto:
> > Which shows quite nicely that any kind of D-Bus related services that
> > want to be infrastructure for Free Software desktop systems will have
> > their D-Bus interfaces as the official API.
>
> Yes, but the scenario here is pretty different. There is no DBus API for
> PolicyKit, and we need to rely on its API only. Take a look at this
> function:
>
> polkit_tracker_get_caller_from_dbus_name(Context::instance()-
>
> >getPolKitTracker(),
>
> dbusName.toLatin1().data(),
> &dbus_error);
So this then does some D-Bus call that's so secret that it can be done
directly?
> This function is the only way to access the PolicyKit API for that matter,
> and it explicitely requires a DBusError as a parameter, since PolicyKit has
> no DBus interface, but _handles_ DBus calls on itself, so that's why it
> needs some DBus specific parameters.
That's very uncommon. I had to check the D-Bus spec to see that the interface
header is optional for method calls.
Sounds a bit like security by obscurity.
Probably still doable using low level QDBus API if one can figure out which
object the interface less method calls need to be sent to.
> PolicyKit relies on DBus, but not in the sense of HAL and NM: they expose
> their interface on DBus, while PolicyKit uses DBus for its internals.
Strange design indeed.
Forces all languages other C or C++ to use bindings instead of native
implementations.
> I had the same reaction when Daniel first told me we could have used those,
> but I had to make a step back after having a look at PolicyKit API.
I find it quite unsettling that something which is supposed to be a shared
implementation across projects is so weirdly designed that it basically
enforces the use of a single implementation.
Other efforts are investing lots of time to make sure they can be properly
integrated elsewhere.
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090311/18859a77/attachment.sig>
More information about the kde-core-devel
mailing list