process._debugProcess() 和跨进程检查器激活

🌐 process._debugProcess() and cross-process Inspector activation

kInspector 权限范围限制当前进程打开自己 的 V8 检查器。然而，process._debugProcess(pid) —— 它向外部进程发送操作系统级信号（POSIX 上为 SIGUSR1，Windows 上为远程线程）—— 不受 kInspector 范围或任何其他权限模型范围的限制。

🌐 The kInspector permission scope restricts the current process from opening its own V8 Inspector. However, process._debugProcess(pid) — which sends an OS-level signal (SIGUSR1 on POSIX, a remote thread on Windows) to an external process — is not gated by the kInspector scope or any other Permission Model scope.

在没有额外权限的情况下，以 --permission 运行的沙箱进程可以调用 process._debugProcess(pid) 来强制另一个 Node.js 进程打开其 V8 Inspector。目标进程不需要以 --permission 运行才能生效——任何在同一主机上由同一操作系统用户运行的 Node.js 进程都可以被信号触发。

🌐 A sandboxed process running under --permission with no additional grants can call process._debugProcess(pid) to force another Node.js process to open its V8 Inspector. The target process does not need to be running under --permission for this to work — any Node.js process running on the same host under the same OS user can be signaled.

这与 Node.js 的威胁模型一致：Node.js 信任其运行的操作系统环境。跨进程信号是操作系统级别的功能；限制它是运算符的责任（例如，使用操作系统级别的进程隔离、为每个进程设置不同的操作系统用户，或在 Linux 上使用 seccomp/AppArmor 配置文件）。

🌐 This is consistent with the Node.js threat model: Node.js trusts the OS environment in which it runs. Cross-process signaling is an operating-system-level capability; restricting it is the responsibility of the operator (for example, using OS-level process isolation, separate OS users per process, or seccomp/AppArmor profiles on Linux).

依赖 --permission 来沙箱化不受信任代码的开发者应注意：

🌐 Developers relying on --permission to sandbox untrusted code should be aware that:

• process._debugProcess() 可以从任何没有权限的沙箱进程中调用。
• 如果目标 Node.js 进程在同一主机上以相同的操作系统用户运行，它可以通过此 API 被强制打开其检查器。
• 为防止这种情况，将沙箱和目标进程在不同的操作系统用户下运行，或在 Node.js 外部使用操作系统级的隔离机制。