Subject: Re: Duplicating Unix Domain Sockets
From: egor duda <[email-masked]>
To: David E Euresti <[email-masked]>
Cc: egor duda <[email-masked]>
Date: Tue, 4 Jun 2002 19:23:28 +0400

Hi!

Tuesday, 04 June, 2002 David E Euresti [email-masked] wrote:

>> It's not enough to just pass numerical value of descriptor between
>> processes. Each cygwin fd has several win32 handles associated with
>> it, which are used to actually do the job, to read or write the data,
>> to perform synchronization, etc. If you want to pass fd1 from proc1 to
>> proc2, you have to duplicate all win32 handles associated with fd1
>> into address space of proc2. This can be done by DuplicateHandle ()
>> function, but if you take a look on its docs on msdn, you'll see that
>> it requires process handles of proc1 and proc2 to work. Given that
>> proc1 and proc2 can be absolutely unrelated and run from different
>> accounts, there's no secure way to obtain those process handles
>> without help from some mediator process which run at high enough level
>> of privileges.

DEE> Oh I know it's not enough just passing a number.  I've already got a user
DEE> land application passing file descriptor by passing

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.

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> };

DEE> So basically I pass this info in at the beginning of a packet.  And then
DEE> the receiving end calls DuplicateHandle, followed by cygwin_handle_to_fd.
DEE> It works well except it doesn't mark the right socket types.  i.e. UDP,
DEE> TCP, AF_UNIX etc.  (I've sent the code before search for my name in the
DEE> archive and you'll find it titled "File Descriptor passing fun".

DEE> Another problem with this is that there's a bit of synchronization needed
DEE> because the sending process can't close the socket until it's been
DEE> duplicated.  This will actually happen in the suggestion I had.

>> That's what cygwin daemon is for -- to provide a
>> services that require high privileges to normal non-privileged
>> processes. After such handle duplication service (with appropriate
>> security checks) is implemented in cygwin daemon, it would be simple
>> to augment AF_UNIX sockets protocol to be able to pass auxiliary
>> information such as fds.
>>

DEE> Well as I have to have this to graduate, I could work on this. But
DEE> somebody needs to tell me where to start looking.  Because i've looked
DEE> through the source and I don't really get it.

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

Egor.            mailto:[email-masked] ICQ 5165414 FidoNet 2:5020/496.19

--
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/