[RFC] NSMessagePort and the NSPort hierarchy

[Alexander Malmberg]

Hi,

A while back, I implemented NSMessagePort and NSMessagePortNameServer
(an NSPort-class using unix domain sockets). It's been tested by me and
a few others (big thanks to those who've helped me test it :) and seems
stable:

http://w1.423.telia.com/~u42308495/alex/NSMessagePort-0.5.tar.gz

Untar it in core/base/ and apply the patch. This version is for very
latest cvs of -base. Changes:

* Implements NSMessagePort (_heavily_ based on GSTcpPort) and
NSMessagePortNameServer. These provide system- and user-local DO using
unix domain sockets.

* Moves GSTcpPort to NSSocketPort. This replaces the ... misguided
implementation currently there. Fortunately, this is not a problem:
NSSocketPort.m wasn't listed in GNUmakefile, so it has never been
compiled or included in the library.

* Splits NSPortNameServer into NSSocketPortNameServer with the
NSSocketPort(GSTcpPort) parts and NSPortNameServer with the generic
parts (not much).

* Makes NSPort/NSPortNameServer return
NSMessagePort/NSMessagePortNameServer instances.

The main advantages of having NSMessagePort (and using it by default)
are:

* They're "secure"; remote systems, or other users on the system you're
running things on, can't access them. ("Secure" here does not mean that
it's completely and unbreakably secure in all cases; it does mean that
to break it, you'd need to be able to access files private to another
user, so it'd take something like a root exploit or an exploitable
kernel bug in file permission handling for an unauthorized user to break
it.)

* Since the ports are user-local, GNUstep can be used be several users
on the same system without name conflicts.

* In the common case where only NSMessagePort:s are used, it isn't
necessary to run gdomap. This makes installation easier (especially if
don't have root access), and arguably, one less daemon is a good thing
(especially a suid daemon).

Because of the security reasons, I think it would be good to apply this
as soon as possible. Some issues that need to be resolved first:

* How do we want to arrange the NSPort hierarchy? With more than one
type of port, programs need to be able to create ports of a specific
class. Although GSTcpPort doesn't implement the full NSSocketPort
interface, I think that most of it could be implemented in GSTcpPort,
and it is a good match on a high level (DO port for local and remote use
using tcp/ip). Thus, it seems better to rename GSTcpPort to NSSocketPort
and have programs use this class instead of making GSTcpPort public.

Also, after running with this patch for a while, I'm not sure that
NSMessagePort should be the unix domain socket implementation. Since the
preferred system- and user-local port type will be different on
different platforms, it might be better to make NSMessagePort abstract
and to have it return instances of the correct class depending on the
platform (or on how the program is run; I'd like to provide -NSHost-like
functionality by implementing another NSMessagePort that worked by
tunneling everything to a port server on a different system; thus, when
run with -NSHost, NSMessagePort would use that implementation, and when
run without it, it would use the unix domain socket implementation).

There's also NSMachPort, but it has the same "role" as NSMessagePort,
and can't be implemented meaningfully on most systems anyway.

* Currently, NSPort always uses NSMessagePort, which is consistent with
the docs if you look at port roles (the docs say that it should be
NSMachPort). I guess that for compatibility, and for convenience for
those who understand the security issues, we'd need to have a default
that could be set to pick the "default" port class. GSDefaultPortClass?
(values would be NSMessagePort or NSSocketPort)


Some issues we probably want to look at later:

* GSTcpPort/NSSocketPort and NSMessagePort share _lots_ of code. Doing
it this way was easiest and safest (least likely to break GSTcpPort),
but now that both are working, it should be fairly easy to move the
common parts to a base class and make both inherit from it.


I've been using this patch for about a month now, and (after the final
bugs were fixed :) almost everything runs fine. The exceptions are
programs that assume that [NSPort port] will return a port suitable for
remote DO. Changing these to explicitly use NSSocketPort has fixed the
problems.

- Alexander Malmberg