我拥有一个进程，该进程的文档声称可以将其发送SIGABRT给我，以获取一些调试信息。但是，当我尝试发送时SIGABRT，我得到“不允许操作”的信息。
我还尝试将相同的信号发送给我拥有的其他进程，以确保没有任何阻止我SIGABRT完全发送的底层块，但它们以适当的方式响应。这只是一个程序，但它是该程序的每个实例。该过程的系统调用跟踪显示它从未接收到信号。
我尝试/bin/kill显式运行以排除shell内置文件中的任何怪异现象kill，并且除了一些细微的输出差异之外，行为没有任何变化。
root可以发送SIGABRT到该进程，并且可以按我期望的方式工作。
我玩了一段时间，但从未见过用户无法向其拥有的进程发送信号的实例，也从未见过用户可以发送一个信号但又无法发送信号的实例。没有别的。
操作系统是FreeBSD 9.0，该过程是一个红宝石过程，它是在Apache下运行的Phusion Passenger Ruby-on-Rails应用程序的一部分。
我现在全都亏了。有人知道发生了什么吗？
更新：security.bsd.conservative_signals根据手册页，结果证明sysctl设置为1，从而阻止了许多信号传递给setuid进程。将其设置为0可解决此问题。
虽然在流程链的某个地方有一个setuid调用-该流程是Apache httpd的子代，并且Apache更改了其uid以放弃根权限-该流程本身不是setuid，并且其EUID，RUID和SVUID都是与发送信号的用户相同。该过程的唯一检验我能找到这将表明，任何setuid的发生是P_SUGID在标志ps的‘标志’字段。（“自上次执行以来就设置了ID特权”）似乎不应该这样，但是它是在Apache模块中处理的，我不知道它的确切方法。
记录下来，这是一个ruby进程，它是由mod_passenger，AKA mod_rails处理的Ruby on Rails应用程序的一部分。
为了使进程有权向pid指定的进程发送信号，用户必须是超级用户，或者接收进程的真实或已保存用户ID必须与发送进程的真实或有效用户ID匹配。信号SIGCONT是一个例外，它始终可以发送到具有与发送者相同的会话ID的任何进程。此外，如果将security.bsd.conservative_signals sysctl设置为1，则用户不是超级用户，而接收者是set-uid，则仅发送作业控制和终端控制信号（特别是仅发送SIGKILL） ，SIGINT，SIGTERM，SIGALRM，SIGSTOP，SIGTTIN，SIGTTOU，SIGTSTP，SIGHUP，SIGUSR1，SIGUSR2）。
您在什么意义上拥有流程？与实际uid，有效uid，正在运行的二进制文件，该二进制文件的所有者和setid位有关的进程的确切状态是什么？
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句