lists at astrojar.org.uk
Thu Jul 13 11:55:10 BST 2006
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.
KAlarm author & maintainer.
More information about the kde-core-devel