Skip to content

stop: consider pidfd_open for kernel-enforced PID-reuse safety #109

Description

@eminwux

Follow-up from PR #106. The PID-reuse race in sb stop terminal was closed in 8500b11 by reading `/proc//stat` field 22 (start-time token) and persisting it into `TerminalStatus.PidStart` / `ClientStatus.PidStart`, with pidutil.Match gating signals. See `internal/pidutil/`.

The token approach was chosen because it is portable to existing on-disk metadata and round-trips cleanly as a uint64 through the JSON status doc. Linux's pidfd_open(2) (plus pidfd_send_signal(2)) offers a stronger kernel-enforced variant: the fd refers to the original process regardless of PID recycling, so no comparison is needed at signal time.

Tradeoffs

  • Pros: race-free by construction; no dependency on /proc format; fewer syscalls on the hot path.
  • Cons: the fd must live as long as the target, meaning either the controller holds it for the terminal's lifetime (most natural) or we accept a brief re-open window on signal. Cross-process holding of a pidfd would require a design change in how the controller owns terminal lifecycles.

Out-of-scope work

  • Design how the controller opens / owns / closes pidfds per terminal.
  • Preserve the /proc token path as a fallback for metadata written before the upgrade, or run a migration.

Not urgent — the current token gate is sufficient for the PID-reuse foot-gun. Tracking for later consideration.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions