DBus/QtDBus Concerns
Friedrich W. H. Kossebau
Friedrich.W.H at kossebau.de
Wed Jul 12 14:57:36 BST 2006
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
More information about the kde-core-devel
mailing list