[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: DBus/QtDBus Concerns
From:       "Friedrich W. H. Kossebau" <Friedrich.W.H () kossebau ! de>
Date:       2006-07-12 13:57:36
Message-ID: 200607121557.36364.Friedrich.W.H () kossebau ! de
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]