This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [RFD]: Egor's proposal for a Cygwin server process


On Thu, May 31, 2001 at 08:54:59PM +1000, Robert Collins wrote:
> From: "Corinna Vinschen" <vinschen@redhat.com>
> > Has somebody a suggestion how to interact with that server process?
> > Sockets? Named pipes? Smoke signals?
> 
> Smoke signals. Definately. They will offer us many benefits:
> * We will gain instant cross-platform access. (Smoke signals are
> understood equally well on any binary computer).
> * Lower heating bills for folk in cold places.
> * Smoke Access Protocol (SAP). Derived from the source for SMOKE(wet
> foliage), this protocol offers sticky information tagging, an important
> resource for a wide area system such as smoke signals.

Does anybody know if an RFC exists for IPC using smoke signals?
I know of an RFC for IP over avian carrier but smoke signals...

> More seriously?
> Sockets: I think this offers security issues.
> Named pipes: Ditto.
> 
> I think COM with out-of-process only offers the capability for tight
> integration between the daemon and the process calling it. I'm not
> religious on this - just offering more work for someone else :].

Whatever method we use, it must provide at least the following features:

- Simple standarized protocol which is able to transport _any_ new
  messages. New features in the server should not affect the protocol
  implementation at all.

- Secure transmission of process data (pid, uid, gid) in terms of TRUTH.
  A process should never be able to pretend to be started by another
  user, for example.

> Most importantly: I think that the daemon interface needs a some-what fo
> rmal API for us in the peanut gallery that want to be able to add calls
> to it in the future.

Yep, that's too. But be aware that the interface to the server
process is only meant to be used INSIDE of Cygwin. For example,
the `seteuid()' call could be implemented as a call to the
server in future:

	int
	seteuid (uid_t uid)
	{
	  if (os_being_run == winNT)
	    {
	      cygsrv_message msg;
	      msg.set_message_type (CYGSRV_SETEUID);
	      msg.add_ulong_parameter (uid);
	      msg.call_cygwin_server ();
	      return msg.get_int_result ();
	    }
	  ...
	}

and the cygsrv_message class would implement the actual protocol.

The application interface is and will be the Cygwin DLL. The server
process is just used to do the dirty jobs for the DLL itself.

Corinna

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]