Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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 19:23:28 +0400 From: egor duda Reply-To: egor duda Organization: deo X-Priority: 3 (Normal) Message-ID: <1211471160707.20020604192328@logos-m.ru> To: David E Euresti CC: egor duda Subject: Re: Duplicating Unix Domain Sockets In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi! Tuesday, 04 June, 2002 David E Euresti davie AT MIT DOT EDU 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:deo AT logos-m DOT ru 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/