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