suspected bug in timeout command

David Laight David.Laight at ACULAB.COM
Sat Feb 12 13:13:05 UTC 2022


From: Michael Conrad
> Sent: 12 February 2022 12:59
> 
> On 2/12/22 07:38, Michael Conrad wrote:
> > Correctly using pidfd *still* requires that you be the parent process,
> > else the child could get reaped and replaced before the pidfd is
> > created.  As far as I can tell, the only purpose of pidfd is for
> > waking on poll() instead of using signals, which is orthagonal to this
> > problem.

Even if the pidfd can't be passed down, it lets you verify the process
information and then send the signal.

> > I haven't looked at the source in busybox yet, but it boggles my mind
> > that it wouldn't just be a simple fork+alarm+waitpid because that is
> > literally the least code implementation, and race-free.
> >
> > -Mike C
> >
> Sorry for being lazy.  I looked at the source and this is the reason:
> 
> /* We want to create a grandchild which will watch
>   * and kill the grandparent. Other methods:
>   * making parent watch child disrupts parent<->child link
>   * (example: "tcpsvd 0.0.0.0 1234 timeout service_prog" -
>   * it's better if service_prog is a child of tcpsvd!),
>   * making child watch parent results in programs having
>   * unexpected children.    */
> 
> I don't follow this reasoning.  Does "disrupts the parent<->child link"
> just about sending signals?  If the timeout app relays all signals from
> itself to the child, what remaining problems would exist?

In that case you can pass 'verification information' through to
the grandchild.

It could be an open fd of "/proc/self" - which allows the non-racy
kill on recent kernels.
But other information would allow the timing window be minimalised on
older kernels.

ISTR that on older kernels an open fd to "proc/nn" always refers to the
current process with pid nn. But the actual behaviour is worth checking.
I think newer kernels will fail any reads after the process has exited.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)



More information about the busybox mailing list