[Top][All Lists]

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

Re: [RFC] NSMessagePort and the NSPort hierarchy

From: Richard Frith-Macdonald
Subject: Re: [RFC] NSMessagePort and the NSPort hierarchy
Date: Mon, 14 Jul 2003 06:57:52 +0100

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


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


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


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

* 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

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

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.

reply via email to

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