| www.delorie.com/archives/browse.cgi | search |
----- Original Message ----- From: "egor duda" <deo AT logos-m DOT ru> To: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au> Cc: <cygwin-developers AT cygwin DOT com> Sent: Wednesday, April 18, 2001 9:23 PM Subject: Re: handle protection - please comment > Hi! > > Wednesday, 18 April, 2001 Robert Collins robert DOT collins AT itdomain DOT com DOT au wrote: > > RC> Place them in a a list in a shared memory area. That is essentially what > RC> kernels do. No process memory access is needed. > > They _are_ in shared memory area already. Passing handle value (via > shared memory area or by other means) from process A to process B is > _not_ enough to use it in process B. win32 handles _must_ be > duplicated after they were passed from one process to another. Doh!. I finally read up on DuplicateHandle and I think I grok the issue now. In my words: you cannot duplicate a handle from process A to B without both process handles. And I assume that there are vulnerabilities in NT related to having process handles irrespective of user privileges. (I thought all you needed was access to the handle in shared memory + dup access to the process that owns the object :[ ). There is a third mechanism though: named objects. That's how I implemented fifo's. (Named shared memory + named mutexs + named event objects). If the object doesn't have a path name per se, you can create predictable names to allow others to open the object. Win9x will be an issue with pipes though, unless we move to my fifo code :-/ (I'm not suggesting that we do.) Rob > i know only 2 things in win32 api which allow using a handle from one > process in another -- either inheritance or DuplicateHandle(). If you > know some other way, it'd be nice to see the proof-of-concept code. > > Egor. mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19 > > >
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |