进程运行时Linux procfs索引节点号已更改

我正在为Linux开发安全软件（SW）。 我们的软件所做的一件事是，当某个进程启动时，SW stat（）会记录进程的/proc/entry，并记住该条目的inode编号。 稍后，当软件需要确定进程仍在运行（并且尚未重新启动）时，它会再次查找进程的inode，并与记住的inode进行比较。 一切都很顺利，直到最近我才开始收到一个特定应用程序的错误警报——Opera browser 11.10beta。 基本上，Opera在运行时，其/proc/PID条目的inode编号发生了变化，我们认为这是不可能的。 在软件的安全概念中，这是一个相当大的难题——它很大程度上依赖于这样一个事实：当进程运行时，其/proc/entry的inode保持不变

有人能告诉我为什么会出现这种行为吗。

---

谢谢。

+1感谢您的防御性编程习惯

免责声明 以防它不是恐怖的：我只是在这里进行头脑风暴。很明显，我们不能马上给出答案，我的想法不适合评论；我将删除此项，因为它不会导致解决方案

我一定要确保歌剧没有自己分叉（对不起，这可能会侮辱你的智慧：）

接下来，看看名称空间和chrooting

编辑

编辑

我想说，进程ID必须已经更改（或者对用户进程可见的procfs重新装载）：

在/proc下，我们可以找到一般系统信息和特定过程信息及统计信息。Linux使用inode编号区分不同类型的信息。Linux中的索引节点号表示为32位数字，PID（进程标识符）表示为16位数字。使用此模式，Linux将索引节点号拆分为16位的两半。左半部分解释为PID编号，右半部分解释为一类信息。由于PID=0无效，Linux使用此值指示inode包含全局信息。（）

---

感谢sehe指出了正确的方向，感谢Random832最终锁定了它。 我运行了一个进程并监视它的PID ls-I/proc/21314。唉！该目录下的每个条目都在大约15分钟后更改了其inode编号。

---

因此，inode编号在procfs中从来就不是永久性的：（

Hi，我确信没有fork（），因为fork（）的子代会有一个不同的（与父代不同的）PID。在我的例子中，Opera没有退出或什么，它有PID 1716，当我浏览网页时，我做了
if（stat（“/proc/1716“，&statbuf）=-1）退出（）；if（oldinode！=stat.st\ino）alert（）；
因此/proc/1716的inode编号已更改（opera仍在运行）。@abirvalg:我打赌是碎片整理，尽管它需要更多（代码）分析；您能否验证非目录节点的inode是否已修复（或者它们是否也在同时更改）？当然，上面是一个模型代码。所有inode值都是printf（）到控制台并使用ls-i签入/proc/proc@abirvalg：我从未怀疑过这些值的正确性。我的具体意思是，目录索引节点的“永久性”与procfs上的文件索引节点之间可能存在区别。从描述中，我觉得文件索引节点应确定地依赖于PID、目录索引节点、，现在不太确定了，索引节点号是64位，而PID是31位。浏览procfs源代码表明，在访问文件系统时，大多数索引节点都是动态分配的。我现在检查了其他应用程序，发现Firefox和传输在运行大约20分钟后会出现这种症状。你是根据什么判断的您是否认为inode更改是不可能的？这意味着相反。您似乎可以检查process dir上的时间戳以查找进程开始的日期…也许这将是一个解决方案，可以防止在您有机会注意到PID退出之前重用它的可能性已经很小。谢谢或者提示！在我开始使用/proc/PID/stat的stime时（系统启动后的时间）字段。即使系统时间被篡改，内核也会为新进程分配越来越大的时间间隔。在保证系统时间不被篡改的环境中，您提出的解决方案可能很有用。感谢您使用

/proc/PID/stat

的starttime字段（非时间间隔）（

cut-d'-f22

）。如果您编辑您的答案以包含此信息，而不是在没有解决方案的情况下漫无目的地说下去，那会更好。