Mark,
On 11/25/20 12:49, Mark Thomas wrote:
On 25/11/2020 16:46, Christopher Schultz wrote:
<snip/>
Strange that the library is getting a direct reference to the response's
file descriptor. That seems (to me) to be a tactical mistake in an
implementation. Then again, I'm not looking at what is actually being
accomplished, there... it may make perfect sense in context.
The library creates a pipe and so gets two file descriptors. It closes
the file descriptors so they are returned to the OS's pool of file
descriptors. Shortly afterwards the OS reuses one of the file
descriptors and assigns it to the socket. So far, so good. Then the
library closes the file descriptors for a second time and that closes
the socket.
That would do it for most situations, but this is a child process
closing a file descriptor twice. It shouldn't break the parent process,
should it? I mean, if I could write a program that could steal fds from
its parent process, that would be a pretty big security bug.
Or is the issue that this is actually a "thread process" and not a
completely separate process, so they share a fd pool?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
