viability of implementing global shortcuts via KDED and DBus

Andreas Hartmetz ahartmetz at
Fri May 11 07:49:09 BST 2007

On Friday 11 May 2007 06:45:14 Thiago Macieira wrote:
> Andreas Hartmetz wrote:
> >-What about security? Only real KGlobalAccel objects should be able to
> > talk to the KDED module in all circumstances. There seem to be
> > provisions for this in DBus, but how do they work, especially in
> > QtDBus?
> Forget it. There is no security. Anyone can impersonate any object on the
> session bus.
Hmmm... If an attacker has an application running with the user's rights, it's 
too late anyway. I forgot that, and it should be OK.
I guess that KJS and friends won't let any script from the internet send DBus 

> >-How long are typical DBus method invocation times? Shortcuts should
> > trigger their actions with no noticeable delay. Assigning saved
> > shortcuts to their actions at application startup time should be very
> > fast, too.
> If the system is idle, the roundtrip should take less than a millisecond.
That would be good enough.

> >-If an application shuts down unexpectedly, can one be 100% sure that
> > KDED will get to know it immediately?
> No. It depends on the system load. The D-Bus daemon will tell KDED that
> the application exited as soon as it itself finds that out, but how soon
> kded will process that is unknown.
That should be good enough, too.

> >-Synchronous calls will probably be needed in places where atomic
> > updates will be required to prevent race conditions (not sure if that
> > happens). Can synchronous calls be made lockup-proof? A locked up
> > application should never be able to block the KDED module. On the other
> > hand, locked up applications should still receive updates to their
> > actions ASAP :/
> It can be made lockup proof if you design it so. A synchronous call always
> has the possibility of deadlocking, however. You just have to make it
> extremely unlikely.

OK... I have a feeling that it can't be made to behave 100% correct in all 
corner cases and be lockup proof at the same time. So be it.


More information about the kde-core-devel mailing list