12cc6b3e
From: gneuner2@comcast.net
On Sat, 2 Jun 2012 23:06:53 -0700 (PDT), Joshua Maurice
wrote:
>I've never understood why people would want "inherit on fork" by
>default. The process is the default go-to for fault tolerance and
>fault isolation, and security. This is just a huge gaping hole that
>is /so/ onerous to plug.
I agree that inheritance should not be default, but historically the
reason is obvious - forking a new process was the only way to
multiprogram an application, and inheriting resources allowed the
independent parts to communicate.
Fork() was most interesting because the child could continue executing
the parent's code from the point where the fork occurred. This is a
useful feature even if 99.44% of the time the child process intends to
immediately execute a new program. CreateProcess always starts the
program from the beginning ... although technically possible, it is
very cumbersome to clone a Windows process and achieve a Unix-like
fork.
>Some of the "reliable" but non-portable ways to solve this problem
>are: closefrom, /proc/self/fd, F_MAXFD, and some obscure option to
>CreateProcess available for Windows Vista or later.
> :
>In one regard, the win32 API is far superior [to POSIX] - it allows
>process spawning while inheriting only the handles in a specific list.
>However, as far as I can tell barely documented at all.
Not exactly.
The Win32 API has had process handle inheritance control right from
the beginning, and it always has been documented. I'll certainly
agree that the online help provided with the compilers could have been
better (though it is all there), but there have been numerous books
that covered these security issues thoroughly.
There is no way to provide to CreateProcess a list of particular
parent handles to be inherited by the child. Inheritence is
controlled indirectly by the security attributes of the individual
open handles.
The SECURITY_ATTRIBUTES (SA) structure contains the boolean flag
"bInheritHandle" which determines whether a handle created with the
attributes can be inherited. Any Create/CreateEx call that takes a
SECURITY_ATTRIBUTES structure can permit or restrict inheritance of
the resulting open handle.
CreateProcess has a boolean argument "bInheritHandles" which is a
blanket restriction on inheritance. When set to false it prohibits
any handles from being duplicated in the child. When set to true,
only those parent handles whose security attributes permit inheritance
are duplicated in the child.
Unfortunately, most resource handles can be inherited by default. You
have to deliberately choose to restrict them - either by prohibiting
all inheritance in CreateProcess or by setting inheritance attributes
on a per-handle basis. It definitely would be easier if you *could*
directly provide a list of handles to CreateProcess.
Windows is not POSIX compliant[*] and certain POSIX semantics simply
can't be supported. YMMV, but when developing serious applications on
Windows, IMO it is better to use the native API as it was intended
rather than trust in the interpretation of a quasi-POSIX C/C++
library.
[*] AFAIHS, there is no system that is fully POSIX compliant.
Moreover, many of POSIX's semantics are unclear - some particularly
troublesome issues have been discussed at length in comp.arch (where
it seems nothing computer related actually is off topic 8-)
>PS: Fun fact: I actually misused the win32 CreateProcess option
>because of the poor documentation, and got a blue screen. (After a
>hard reset, I took another guess and it worked.) Apparently it doesn't
>get much use - probably again because you have to opt-in to have
>security and be leak-free, which reeks IMO of bad design.
Never had CreateProcess itself blue screen, but I can easily see the
child process blowing up due to a broken environment.
George
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
