正确的kill syscall linux使用模式

对于

int kill（pid\u t pid，int sig）表示：

如果pid等于-1，则sig被发送到
呼叫进程有权发送信号，进程1除外
（init），但请参见下文

这是否意味着如果我的程序是以root权限运行的，并且它意外地（由于内存损坏或黑客攻击）提供了
-1
作为
pid
参数-这将导致整个系统的完整DoS

如果是这样，是否建议在调用此可能有害的调用之前，始终对
pid
参数值执行双重检查？（只是说说而已）

这是否意味着如果我的程序以root权限运行，并且
意外地（由于内存损坏或黑客攻击）提供-1作为pid
参数-这将导致整个系统的完整DoS

是的，这种情况是可能的。但这种情况发生的可能性非常小。因为没有使用root权限运行的程序会做这样的事情。如果恶意用户/二进制文件以某种方式获得了root权限，那么发送信号只是问题之一

如果是，是否建议始终对pid执行双重检查
调用此潜在灾难性调用之前的参数值

那只是超级偏执的想法。有成千上万种方法可以进行灾难性的活动。您可能还需要担心：

如果没有在系统启动时运行的恶意守护程序，该怎么办

kill(-1, SIGKILL);

您如何知道您创建的库函数是否不会调用
reboot（2）
并重新启动系统

等等

此外，PID不仅仅是需要清理的用户提供的值。PID主要是在程序中使用系统调用或库调用获取的值。因此，“意外”使用-1的几率为零。基本上，你的某人/程序拥有root权限，并决定破坏你的系统，那么你就无能为力了。
为什么你的程序会再次以root权限运行？@FrédéricHamidi这与这个问题有什么关系？显然，存在需要以root用户身份运行的程序。让我们假设我们正在谈论它们。@John，那么这些程序在任何情况下运行时都应该非常小心，而不仅仅是在调用
kill（）
时。如果您在担任root用户时轻率地处理系统调用，那么有无数种方法会破坏您的系统，
kill（）
在这方面并不特别--
write（）
实际上更糟糕。现在，我们是否应该再次检查
write（）
是否仅在内存损坏或黑客攻击的情况下才接触MBR？@FrédéricHamidi：为什么不将您的两条评论合并到一个答案中？我同意不要将您的程序作为根目录运行，因为它解决了我的问题。几乎任何用户空间程序都可以配置为以非特权用户的身份运行，应该这样做