Re: Using unix sockets for NSPort

[Alexander Malmberg]

Richard Frith-Macdonald wrote:
[snip]
> > The difference is: when you ask for a generic NSPort, you get a
> > GSMessagePort (a subclass of NSMessagePort with a private directory as
> > its
> > "staging area"). This is the only real difference from the Apple
> > implementation. By default, Apple returns an NSMessagePort
> 
> Yep ... I think this would be a good default ... when we have a
> thoroughly
> robust implementation of such a private DO system.

I agree. A defaults key could switch back to the old behavior, but it
should be threateningly named.

> >>> 1. Security. Nobody else can connect to your services or mess with
> >>> your pasteboard. Apps only connect to your ports, so nobody can set
> >>> up
> >>> an evil pasteboard and store everything you cut/copy/select (or
> >>> change
> >>> it; ever pasted something in a terminal?).
> >>
> >> It might well make sense to do this ... it would prevent use of
> >> Xterminals with GNUstep apps, but that might not be important.
> >
> > I don't think it does. With an X terminal, all of the executables are
> > always running on the app server, and so can all communicate with each
> > other. There's no pasteboard server running on an X terminal, nor is
> > there
> > a distributed notification server.
> 
> But not all executables are necessarily running on the *same* app
> server!
> 
> Also, an Xterminal is actually a special case of the more general
> problem
> of apps using -NSHost to work on a different display to the machine they
> are executing on.
> Really, we should try to think of a proper solution to the security
> issues
> implied by remote hosting.  I don't think simply disallowing it is very
> good.

Simply disallowing doesn't solve the problem, but neither does the
current system, and simply disallowing is secure.

It is possible to solve this, but in practice, we probably won't be able
to do it when we're running on 'normal' windowing systems. In a perfect
system, I think each "display" would have its own private namespace. In
practice, we can get a private namespace for a user on the displaying
host (so several displays on one system with the same user would share
one namespace) by tunneling apps over the display server when running
remotely. There'll still be security concerns, but only in one place.

(This is how I plan on handling this with the rds stuff.)

[snip]
> Hooks for easy SSL encryption
> Hooks for data compression perhaps

These would be useful, especially the encryption. Not so sure about a
security framework; we probably shouldn't try to do too much in the
library classes.

> My guess is that modifying GSTcpPort to support unix sockets would be a
> much faster
> route to this than adding the required features to the example code
> code alexander
> supplied, on the other hand his example nameserver code looks usable
> with minimal
> alteration already.

That's probably true. I'll have a look at refactoring things this way.

- Alexander Malmberg