Re: [Sshpass-devel] SIGCHLD blocking?

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

<html style="direction: ltr;">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
  </head>
  <body bidimailui-charset-is-forced="true" style="direction: ltr;"
    text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 05/07/18 05:29, Martin Galvan wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAN...@ma...">
      <pre wrap="">Hi all,

I'm looking at the sshpass code, and noticed the following: in
runprogram, SIGCHLD is blocked for the parent process after the fork
is done. Shouldn't the blocking be done before the fork, restoring the
old sigmask for the child if needed? What would happen if the child
finishes for some reason before the parent blocks the signal? If the
answer is that pselect would still return successfully, then what's
the point of blocking the signal in the first place?

</pre>
    </blockquote>
    Generally speaking, that's not a very good argument. The race is not
    between the parent and the child, it is between the signal and
    checking the handler's results. As such, there is no problem <b>in
      general</b> with the code structure as it is.<br>
    <br>
    In sshpass's particular case, however, you are right - there is a
    race in the use case you mention. The reason there is a case is not
    because the child might send a SIGCHLD before we block it. It is
    because we call "waitpid" <i>after</i> we call pselect (thus, if
    the signal arrives before we block it, we won't get around to
    releasing the process until the select returns for whatever other
    reason). This is also the reason that there is no corresponding race
    for the other signals - their side effect (setting term) is checked
    before we dive into the select.<br>
    <br>
    This was a very elaborate and round-about way to say "good catch.
    Thank you".<br>
    <br>
    I'll fix it, though probably not by blocking SIGCHLD before the
    fork. That would only require unblocking it in the child process,
    adding a redundant  system call and making the code less clear.<br>
    <br>
    Thank you again,<br>
    Shachar<br>
  </body>
</html>