Re: Using unix sockets for NSPort

[Jeff Teunissen]

Richard Frith-Macdonald wrote:

> On Thursday, October 3, 2002, at 06:55  pm, Alexander Malmberg wrote:

[snip]

> > NSMessagePort uses unix domain sockets (instead of tcp/ip sockets),
> > and puts the registered names in {NSTemporaryDirectory()}/ports/
> > (usually /tmp/username/ports/). Thus, the ports are private to the
> > user who created/registered it. The two main advantages with this are:
> 
> That's great ... I've long meant to get round to writing unix domain
> ports for better performance when both ends of a connection are on the
> same machine.
> 
> But I'm not sure that a local port type should be the default port type
> ... that would break backward compatibility with OpenStep and all
> existing apps - so we should probably add another compatibility user
> default to control this.

IMO, this is a case where both the OpenStep spec is clearly wrong for a
multi-user system, and Mac OS X's implementation is partially wrong; the
default case should always be as secure as possible. NeXTstep, OPENSTEP,
and Mac OS X are essentially single-user operating systems -- two users
can't really log on graphically at the same time, and the safety aspects
of having the pasteboard server connected to from another machine, or of
having applications being talked to by apps on other systems, isn't seen
as that big a problem -- and for the most part, it isn't on those systems.
But on the systems where GNUstep runs (except for Windows, which is
already riddled with such security holes), it's a long series of disasters
waiting to happen.

However, the OS X implementation does (almost) provide a way to do the
right thing. My suggestion is:

If you ask specifically for an NSMessagePort, you get the Apple behavior:
a port that is public to the machine, but not available to the network.
Apple supports this method, so it's not a deviation from that "spec".

If you ask for an NSSocketPort, you get pretty-much exactly what GNUstep
has now with NSPort -- something that works both locally and across the
network if it's registered.

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.

> > 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.

> > 2. Several users can run apps on the same system. Currently, only one
> > user can register a name on a system. With this implementation, each
> > user gets a private namespace for ports, so they can all run
> > gdnc/gpbs/apps without any risk of messing things up for some other
> > user.
> 
> I think this makes sense for gpbs/gdnc (with the caveat about
> Xterminals) Not so sure about apps ... Obviously anything wanting to
> offer general services would not want to use private single user
> connections.

and hence, NSSocketPort. :)

[snip]

> Sounds like a nice overall structure, but I'm not ready to scrap the
> existing implementation ... it's robust, efficient, safe.   Looking at
> your code I can see a simplifying assumptions made because unix domain
> ports are fast and reliable (would be inappropriate for a tcp sockets
> port), and no support for threading or timeouts ... so I'd suggest
> making a thread-safe version for local messaging, and making it work
> non-blocking so that a failed remote process won't hang your
> application.

I don't think the existing implementation would need to be scrapped --
rather, refactored a little. As far as I can tell, most of it can be moved
wholesale into the more comprehensive architecture.

[snip]

-- 
| Jeff Teunissen  -=-  Pres., Dusk To Dawn Computing  -=-  deek @ d2dc.net
| GPG: 1024D/9840105A   7102 808A 7733 C2F3 097B  161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Project        http://www.quakeforge.net/
| Specializing in Debian GNU/Linux              http://www.d2dc.net/~deek/