Il Sab 12 Feb 2022, 14:13 David Laight <[email protected]> ha scritto:
> 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. > Checking the procfs man page there is some mount options that do not allows reading other PID files in that filesystem. I am not 100% sure that a invitered file descriptor could not be read but negate access. Mount options The proc filesystem supports the following mount options: hidepid=n (since Linux 3.3) This option controls who can access the information in /proc/[pid] directories. The argument, n, is one of the following values:
_______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
