discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: D-BUS versus GDOMAP (WINDOWS users please note)


From: Rogelio Serrano
Subject: Re: D-BUS versus GDOMAP (WINDOWS users please note)
Date: Tue, 31 Aug 2004 15:59:39 +0800

On 2004-08-31 15:51:45 +0800 Richard Frith-Macdonald <address@hidden> wrote:


On 31 Aug 2004, at 08:04, Rogelio Serrano wrote:

I think DO is more like the libdbus layer not the message bus layer.
Yes, the encoding and transport part of DO (eg NSPortCoder and NSSocketPort) is conceptually similar to libdbus, While the nameserver part of DO is (very roughly) comparable to message bus, it's actually quite different.

[snip]

That sounds like a good idea. The main issue (after implementing basic functionality to start/stop services by name of course), is how to combine ease of use with security. While dbus provides a specific security protocol to authorise connections via a variety of mechanisms, this really rather misses the point. Passing authentication tokens and encrypting stuff is fairly straightforward (the GNUstep DO system can already do it) ... what's important is working out how to easily configure the processes to have the correct security tokens and enforce the security policies. We don't have any way to do that now, and d-bus wouldn't help.

IMO what would be good would be to write a proxy class to handle security issues over DO (a server would only vend these proxies rather than vending objects directly), and write easy to use gui and command line tools for configuring policy and security tokens for applications. The NSConnection class could then be trivially modified to check that, when setting a root object for the connection, the object was an instance of the security proxy class.




Hmmm... DTE? Amoeba like capabilities? A user space security server? Selinux?

--
Blood is thicker then water... And much tastier
                            John Davidorff Pell





reply via email to

[Prev in Thread] Current Thread [Next in Thread]