Linux procfs inode number changed whill process was running

I'm working on security software(SW) for Linux. One thing that our SW does on is that when some process is started, the SW stat()s the process's /proc/ entry and remembers the entry's inode number. When later on the SW needs to ascertain that the process is still running (and hasn't been restarted), it again looks up process's inode and compares to the one remembered. All was fine and dandy until recently I began receiving false alerts for a specifc application - Opera browser 11.10开发者_如何转开发beta. Basically it appears that while Opera was running, the inode number for its /proc/PID entry has changed, which we considered an impossibility. This is a rather big spanner in the works of the SW's security concept - so much relied on the fact that while a process is running, its /proc/ entry's inode remains unchanged.

Could someone please advise as to why such behaviour may be exhibited. Thanks.

---

+1 for the defensive programming habits.

_{Disclaimer In case it isn't obious: I'm just brainstorming along here. It is clear we cannot just give the answer instantaneously, and my thoughts didn't fit in a comment; I will delete this is it doesn't lead to a solution}

I'd certainly make sure that the opera hasn't forked/exec-ed itself (sorry that probably insults your intelligence :));

Next, have a look at namespaces and chrooting

• http://vincent.bernat.im/en/blog/2011-jchroot-isolation.html
• http://manpages.ubuntu.com/manpages/oneiric/man1/schroot.1.html

Edit

• [patch 08/12] procfs: inode defragmentation support

Edit

I'd say that the process ID must have changed (or procfs remounted, visibly to the user process?):

Under /proc we can find general system information and specific process information and statistics. Linux distinguishes different types of information with the inode number. An inode number in Linux is represented as a 32 bit number and a PID (Process Identifier) is represented as a 16 bit number. With this schema, Linux splits the inode number in two halves of 16 bit. The left half is interpreted as a PID number and the right one is interpreted as a class of information. Since a PID=0 is not valid, Linux uses this value to indicate that inode contains global information. (source)

---

Thanks to sehe for pointing in the right direction and to Random832 for finally nailing it. I ran a process and monitored its PID ls -i /proc/21314 . Alas! Every single entry under that directory had its inode number changed after approx. 15 minutes. So inode numbers were never meant to be permanent in procfs :(