DBus/QtDBus Concerns

[Friedrich W. H. Kossebau]

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.

So I could at least see some uses for this feature (Alright, I do not need it 
myself right now, but...)

Regards
Friedrich