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