Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: Mon, 3 Sep 2001 14:03:32 +0200
From: Corinna Vinschen <vinschen AT redhat DOT com>
To: cygdev <cygwin-developers AT cygwin DOT com>
Subject: CYGWIN SERVER: Some questions
Message-ID: <20010903140332.C23714@cygbert.vinschen.de>
Reply-To: cygdev <cygwin-developers AT cygwin DOT com>
Mail-Followup-To: cygdev <cygwin-developers AT cygwin DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i

========================================================================
     FOOD FOR DISCUSSION  FOOD FOR DISCUSSION  FOOD FOR DISCUSSION  
========================================================================

I have some questions about our "Cygwin server project" which is
about to start as soon as we have discussed how to implement
the client/server protocol and how to manage differences between
NT and 9x based OSes.

The most important question IMO is, how do we design the communication
protocol? It should combine all qualities which can't live together in
reality but only on marketing papers:

1. Platform independent (from a Wincentric point of view, 9x/NT)
2. Fast
3. Reliable
4. Secure
5. Easy to use
6. Expandable

What did we found to date? We already discussed the transport layer
back in June but we have no result so far. Possible transport layers
are:

- Sockets (Pro: Platform independent, Easy to use, Con: Secure)
- Shared memory (Pro: Platform independent, Fast, Con: Secure)
- Named pipes (Pro: Secure, Con: Platform independent)
- DDE (Pro: Platform independent, Secure, Con: Easy to use???)
- RPC (Pro: Platform independent, Secure, Con: Easy to use???)
- COM (Pro: Platform independent, Con: Easy to use???)

I've recently looked into the MSDN and while I've no idea how to
use RPC (I'm talking about the Windows version, not ONC RPC) and
just a bit of knowledge about DDE (one client/server app 5 years
ago) I'm under the impression these two methods could be the way
to go. Both are available on 9x and NT and both have the
`ImpersonateClient' feature to be securable against unprivileged
access.  If we prefer speed we should take shared memory but we
would then need another protocol for user context sensitive 
functionality like S_ISUID stuff.  Anyway, food for discussion.

The next thingy is, how to implement the high level protocol?
It should be expandable so that a new server feature doesn't
neccessarily imply a change in the protocol e.g. by using
a function oriented interface like open_server(), write_server(),
read_server(), close_server() with a defined structure or string
for sending and receiving data.  Or we prefer the ease of use over
the easy expandability.  A C++ class oriented interface comes to mind.
Anyway, food for discussion.

Which functionality would be thankful to be implement using a server?
Currently I know of

- Secure tty's (No access to other processes handles).
- suid, sgid applications (start a privileged app on behalf of a non-
  privileged app).
- ipc (shm, sem, msg).
- pthreads synchronisation stuff (did I get that right?)
Let's add stuff here as it comes.

I would like to ask you all if, and if, how much you want to get
involved in that project? Which part do you want to care for?

E.g. I would think that the suid,sgid stuff has to be done by
Chris and me since Chris is the Hoodoo Woodoo fork/exec man
who could care for a correct fork when a privileged process
(the server) forks _another_ non-privileged process (the client)
to change the user context which brings me into the play.

Hoping for enthusiastic replies,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin AT cygwin DOT com
Red Hat, Inc.