Huh? I don't have time to try it now, butre you saying that _by
default_, doing nothing special, not only is the underlying SOCKET
handle in the Socket class inheritable, but the Process class is
starting the process with bInheritHandles set to TRUE?
That sounds like a very serious security bug to me. Want access to some
inheritable handle in a process that starts other processes? No
problemust replace a known target child process executable with your
own, and voil carte blanche access.
Can you post a concise-but-complete code example demonstrating it?
>>> Frankly, I'm still not even sure sharing a socket is the best approach.
>> I'd agree there are better ways, but there are several telnet servers
>> already available that may not support those other ways. The only one
>> they all have in common is sharing a socket, so that's what I'm stuck
I guess I don't really get why, just because other telnet servers
implement it this way, you feel yours needs to. The way I suggested is
more general purpose (works with any random console application), while
depending on handle inheritance requires the cooperation of the child
process (you still need to pass the handle value to the child process,
so it knows _which_ handle to use).
But, whateverf you insist on doing this, I guess you can share handles
if you like. I also don't understand why an inherited handle wouldn't
have the same behavior as a duplicated one; that is, it should have to
be closed in all processes in which it's valid before the OS object is
actually closed. But since it's not a technique I'd use in this way,
I'm not going to worry too much about that. :)