DBus/QtDBus Concerns

[David Jarvie]

On Thursday 13 Jul 2006 10:31, Thomas Zander wrote:
>On Thursday 13 July 2006 01:50, David Jarvie wrote:
>> KAlarm and kalarmd need to interact via D-Bus. If some other
>> application made certain D-Bus calls, alarms could be lost. 
>
>Only if those applications were malicious. If you expect things to get 
>lost due to bugs, I suggest you take a long look at the interaction you 
>have via dbus since that may need some work ;)

I'm thinking more in terms of people trying to do clever things with the "private" 
interface, which might mess things up.

>> So it seems 
>> a sensible precaution to check the sender (just as was done in KDE 3
>> using DCOP).
>
>Well, in this case I can see how someone might want to write a kalarm 
>replacement in their own way. There are lots of things I can think about 
>where this is usefull. For example one of the online TVGuide providers 
>that have a Java swing client might want to add an alarm to kalarmd 
>instead of inventing their own alarm daemon.
>
>What you are suggesting is to close the alarms modification to one client 
>only. I think this is fundamentally the wrong path to walk down.
>
>If you are concerned with trojans that remove the alarms, then I don't 
>know what to answer except that there are a lot easier way to corrupt the 
>alarms. Simply killing the daemon might be one of them.

The alarm daemon never adds, deletes or modifies alarms. Only KAlarm can do this, and it has 
public D-Bus functions for this purpose. Where things could potentially fall down is in 
setting the triggered status of alarms, etc. A simple check that the messages come from the 
relevant client application is a simple and obvious way to prevent intentional or 
unintentional loss of alarms.

--
David Jarvie.
KAlarm author & maintainer.
http://www.astrojar.org.uk/linux/kalarm.html