[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using unix sockets for NSPort
From: |
Richard Frith-Macdonald |
Subject: |
Re: Using unix sockets for NSPort |
Date: |
Fri, 4 Oct 2002 18:26:18 +0100 |
On Friday, October 4, 2002, at 01:17 pm, Jeff Teunissen wrote:
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.
Yep ... currently *very* insecure ... though the existing DO API
provides
for secure DO authentication, nothing actually uses it. While I can't
see
gdnc information beng very important, the pasteboard info is potentially
quite sensitive.
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
Yep ... I think this would be a good default ... when we have a
thoroughly
robust implementation of such a private DO system.
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.
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.
Well, I don't care about scrapping the existing code as long as we
replace
it with something better.
I want the following features of the existing code -
high reliability ... well tested/bug free.
fault tolerant ... mustn't hang the process if the other end fails to
respond etc.
high performance ... must not use threads for instance.
thread safe ... so if someone wants to use threads they can use DO
between them.
And I'd really like to add some extensions -
A security framework to provide access control for DO servers ... not
sure about
what exactly this should do though. Certainly it would be nice to have
a two level
system, so that the system manager could enforce some security
policies, and provide
defaults for others (which individual users could override).
Hooks for easy SSL encryption
Hooks for data compression perhaps
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.
Re: Using unix sockets for NSPort, Helge Hess, 2002/10/04
Re: Using unix sockets for NSPort, Alexander Malmberg, 2002/10/04