RFR(xs): 8224181: On child process spawn, child may write to random file descriptor instead of the fail pipe

[Thomas Stüfe]

Thanks Martin for the second review! I'll fix the close call and then I'll
push.

Cheers, Thomas




On Wed, Jun 5, 2019 at 8:35 AM Martin Buchholz <martinrb at google.com> wrote:

> Huh, looks like an ancient bug of mine that doesn't trigger in practice.
>
> Looks good, except change FAIL_FILENO to fail_pipe_fd below (that also
> won't make a difference in practice)
>
>  386     close(FAIL_FILENO);
>
>
>
> On Tue, Jun 4, 2019 at 11:01 PM Thomas Stüfe <thomas.stuefe at gmail.com>
> wrote:
>
>> Hi Martin,
>>
>> can you quickly chime in on this, this is a very small patch and I'd like
>> to get it from my table for JDK13.
>>
>> Thank you!
>>
>> ---------- Forwarded message ---------
>> From: Thomas Stüfe <thomas.stuefe at gmail.com>
>> Date: Tue, Jun 4, 2019 at 3:23 PM
>> Subject: RFR(xs): 8224181: On child process spawn, child may write to
>> random file descriptor instead of the fail pipe
>> To: Java Core Libs <core-libs-dev at openjdk.java.net>
>>
>>
>> Hi all,
>>
>> may I please have reviews for this small fix:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8224181
>> cr:
>> http://cr.openjdk.java.net/~stuefe/webrevs/8224181-on-child-process-spawn--child-may-write-to-wrong-file-descriptor-instead-of-the-fail-pipe/webrev.00/webrev/
>>
>> In sub process error handling code (WhyCantJonnyExec) child signals error
>> to parent by writing an error code to the fail pipe. It does that using the
>> hard wired fail pipe write-end fd (FAIL_FILENO, usually 4). But that only
>> works as intended after the fail pipe write end has been successfully
>> dup2'ed to FAIL_FILENO.
>>
>> If an error happens before that, error code will still be written to
>> FAIL_FILENO, which may be an invalid file handle - which is almost benign -
>> or refer to an unrelated file descriptor the child inherited and did not
>> close yet - which is not good.
>>
>> Cheers, Thomas
>>
>