Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Date:	Tue, 4 Jun 2002 11:33:26 -0400 (EDT)
From:	David E Euresti <davie AT MIT DOT EDU>
To:	egor duda <cygwin AT cygwin DOT com>
Subject:	Re: Duplicating Unix Domain Sockets
In-Reply-To:	<1211471160707.20020604192328@logos-m.ru>
Message-ID:	<Pine.GSO.4.30L.0206041125380.11229-100000@scrubbing-bubbles.mit.edu>
MIME-Version:	1.0

Hello,

On Tue, 4 Jun 2002, egor duda wrote:

> Hi!
>
> Tuesday, 04 June, 2002 David E Euresti davie AT MIT DOT EDU wrote:
>
> Who's filling this structure? If it's sender, then it won't work as
> hHandle has no meaning in receiver. If receiver fills the structure
> then i can't see how normal non-privileged user process can get handle
> of other process possibly running from other account. Even if you
> manage to make it happen, that'd open a security hole -- you'll allow
> receiver to access sender's address space.

The sender is filling in the structure.  And you're right hHandle has no
meaning to the receiving process, except that it does have meaning to
DuplicateHandle,

From MSDN:
BOOL DuplicateHandle(
  HANDLE hSourceProcessHandle,  // handle to the source process
  HANDLE hSourceHandle,         // handle to duplicate
  HANDLE hTargetProcessHandle,  // handle to process to duplicate to
  LPHANDLE lpTargetHandle,  // pointer to duplicate handle
  DWORD dwDesiredAccess,    // access for duplicate handle
  BOOL bInheritHandle,      // handle inheritance flag
  DWORD dwOptions           // optional actions
);

hSourceHandle
Handle to duplicate. This is an open object handle that is valid in the
context of the source process.

So the sending process says, I'm process X, the handle (in my process) is
Y, and the receiver calls DuplicateHandle with (X, Y, MyProcess,
&MyHandle, etc.)  And then you have your duplicated socket handle.  It's
all Kernel magic I believe.

>
> DEE> struct passfd {
> DEE>   unsigned int uiMagic;  // Magic number to see if it's right
> DEE>   DWORD dwProcessID;     // Process ID of sender
> DEE>   HANDLE hHandle;        // Handle in sender's process
> DEE>   BOOL bBinary;          // is it Binary or Text?
> DEE>   BOOL bRead;            // Is it read?
> DEE>   BOOL bWrite;           // Is it write
> DEE>   DWORD dwDevice;        // Device type as listed in windows_device_names
> DEE> in path.cc
> DEE> };
>

>
> Handle duplication code is present in cygserver.cc. It wasn't
> originally designed to pass fds via AF_UNIX sockets, so security
> checks in it may be not what's needed here. What you have to do is to
> pass (via whatever mechanism you like) all win32 handles assosiated
> with particular fd and then make receive ask cygwin daemon to perform
> handle duplication via request similar to CYGSERVER_REQUEST_ATTACH_TTY
>
Currently looking at this.

David



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -