Re: [RFC] NSMessagePort and the NSPort hierarchy

[Richard Frith-Macdonald]

On Sunday, July 13, 2003, at 02:34 AM, Alexander Malmberg wrote:

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

Hmm ... something of a curates egg - see below.

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

Yes ... really good addition.

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

Dubious... I don't think GSTcpPort does quite the same thing as 
NSSocketPort
does in MacOS-X, so this could be misleading (though I agree with
removing the existing NSSocketPort code).

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

Ok.

> * Makes NSPort/NSPortNameServer return
> NSMessagePort/NSMessagePortNameServer instances.

Very bad ... breaks OpenStep compatibility and *lots* of existing code
(all the production code where I work for instance!)
A more sensible thing would be to have NSMessagePort used as
above only when the GSMacOSXCompatible user default is YES.

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

Yes, removing inter-user and inter-host communication obviously
does increase security for people who are running multi-user systems
or unfirewalled networked systems.  I really have no statistics to
say whether that is a large majority or a tiny minority of users.
I'm generally in favour of any increase in security even if it only
effects a few people ... but the most secure machine is one which
is turned off :-)

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

Conversely, they prevent sharing of information with one app supplying
services to many users.

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

If you ever want to use DO for networking, you have to install and run 
the
nameserver, so installation is not made easier (actually it's a while 
since
we have had installation problems reported here anyway, now that the
scripts and documentation are so improved).  Rather, say it would be
possible for people to run a lot of non-network applications even if
gdomap wasn't installed.

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

Many (most?) applications where the GNUstep base library is used
(ie server applications rather than gui apps) expect to use DO for
inter-host communications, and NSMessagePort is useless for that.
As GNUstep-base is production code for many people, breaking
DO in that way would be *very* bad.

That being said, having NSApplication use NSMessagePort (by default)
for its advertised services and for pasteboard operation is probably a
defensible change to the behavior ... I don't think that would break 
things
for many people.

Of course, if we did that, we would need a user default to turn off that
behavior for people who expect to be able to share information.


Pragmatically then, the first priorities I see are -

1. Alter it so that it will compile under windows!  and raise an
informative  if any non-working code is called.
2. Alter the patch so that NSMessagePort and NSMessagePortNameServer
are not used unless explicitly asked for.

Once those changes are in place, it could go into cvs.

After that, we would need to get an NSMessagePort implementation
working for windows.

Then, having working code in place, we could look at what circumstances
to use NSMessagePort in.  The simplest first stage would be when
GSMacOSXCompatibility is YES.  We would probably want to change all
the code that uses NSHost to ignore it and log an error when in macosx
compatibility mode.

A second might be to change the gui code to use NSMessagePort for
pasteboard operations as long as the NSHost user default is not set
(if NSHost is set, the user presumably wants to use a pasteboard on
the specified remote host).

and so on.

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

Actually, Mach ports provided inter-host communications in NeXTstep.
The GNUstep GSTcpPort implementation is the closest thing we have to
Mach ports, as it was designed to support Mach port semantics using a
tcp/ip transport.
Since your NSMessagePort code is modeled on the GSTcpPort code,
it behaves the same sort of way as a limited (usabe by only one user
on one host) Mach port.
My impression is that the MacOS-X NSSocketPort is quite different, and
is really just a socket encapsulation ... which probably means that
MacOS-X NSConnection internals are quite different to GNUstep
(which expects NSPort subclasses to behave like mach ports).

> * 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)

Actually, the OpenStep and GNUstep documentation is for DO as a fully
capable networking system ... so NSMessagePort is not consistent with
that.  The MacOS-X documentation is of course confused ... because
they essentially kept the OpenStep API (where you ask for a connection
to a service on a host), but removed inter-host communication as 
standard.

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

Yes ... certainly we want a minimum of duplication.

> I've been using this patch for about a month now, and (after the final
> bugs were fixed :) almost everything runs fine.

Yes, looks like a lot of good work,

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

That's the vast majority of software where I work (tens of server 
programs
and lots of library classes), and given the maturity of DO in the base 
library,
may be true of lots of other companies too.

So the essentials to get this stuff into cvs without breaking stuff are 
-
1. build under windows.
2. don't use NSMessagePort by default.