On Wednesday 12 July 2006 14:57, Friedrich W. H. Kossebau wrote:
> Am Mittwoch, 12. Juli 2006 15:20, schrieb Thomas Zander:
> > On Wednesday 12 July 2006 04:33, Gary Cramblitt wrote:
> > > 2.  Sender Names.  If you need to know a message's sender, this is
> > > presently rather painful, requiring hand-coding of adaptors.  Knowing
> > > who you are talking to is fundamental.
> >
> > Actually; I implemented various similar frameworks; including one
> > grid-computing solution, and I never ever had the need to find the name
> > of the service connecting to me.
> > This is only needed when encrypting a connection and that implies a
> > handshake which will do something like this anyway.
>
> What about restrictions? A service might want to control whom and how it
> serves.
>
> I heard that a desktop dbus session is limited to a user id (euid or uid?),
> so one would think that a user should be able to do everything the
> operating system allows him. But doesn't interprocess communication bypass
> systems like SELinux/AppArmor? So an access control system might have to be
> implemented within the services? At least I recall some emails by SELinux
> developers on KDE lists, who reported about their problems with kioslaves
> running out-of-process. (Well, could perhaps be implemented in the bus
> itself...)
>
> Or imagine something like KNotify (or its successor) being implemented like
> a dbus service. The client would just signal the event and the service
> would, dependant on it's setting for the caller, create the appropriate
> notification.

KAlarm and kalarmd need to interact via D-Bus. If some other application made 
certain D-Bus calls, alarms could be lost. So it seems a sensible precaution 
to check the sender (just as was done in KDE 3 using DCOP).

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