3

I am investigating Tripwire and have stumbled upon something about which I am unsure. In a tripwire report generated after I modified hosts.deny to include an extra #, I noticed the inode number changed from 6969 to 6915. I would like to know why this happened. I know inodes are records which store data about where data is stored on the file system, but would like to know why this number changed for a simple # being inserted.

Improve this question
2
  • 1
    security related how? (other than you happen to notice this while using tripwire...)
    – AviD ♦
    Commented Mar 5, 2011 at 21:01
  • 1
    Understanding the alerts that one receives is critical to understanding security, even if the underlying cause is not security related. Maybe better at Serverfault, but certainly fine here.
    – Jeff Ferland ♦
    Commented Mar 5, 2011 at 22:17

1 Answer 1

Reset to default
10

This is a common method of editing files in Linux. Your editor opened the file, wrote your new changes someplace (with a new inode), and when that file was completely written it linked the hosts.deny location to the new inode.

The reason this is done is to prevent file locking issues and to avoid partially clobbering a file. In this way, if I remove a file that's open in a program, that program doesn't end up with garbage data. In fact, as long as an inode is referenced somewhere, it remains in-tact.

Improve this answer
1
  • "rename" on Linux is atomic, so it either goes through completely or it does not happen at all. Writing a file in contrast consists of multiple operations. So it may fail in between and leave a partly written file. In order to make it more reliable, most programs write a temporary file and then do an atomic "rename", which changes the pointer to the new inode.
    – Hendrik Brummermann
    Commented Apr 27, 2012 at 8:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .