This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: handle protection - please comment
----- Original Message -----
From: "egor duda" <deo@logos-m.ru>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <cygwin-developers@cygwin.com>
Sent: Wednesday, April 18, 2001 9:23 PM
Subject: Re: handle protection - please comment
> Hi!
>
> Wednesday, 18 April, 2001 Robert Collins
robert.collins@itdomain.com.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@logos-m.ru ICQ 5165414 FidoNet
2:5020/496.19
>
>
>