Subject: Re: Volunteers to test some kernel code...
To: Bill Studenmund <>
From: Brett Lymn <>
List: tech-kern
Date: 06/15/1999 09:18:36
According to Bill Studenmund:
>Don't use dev / inode pairs - use filehandles. Filehandles include
>generation #'s, so they'll catch replacing a file with another which dev /
>inode pairs won't.

I did consider using the generation number but I saw there were a
couple of problems:

1) The generation number is attached to a vnode which is ok - you get
one of those when you open the file _but_ the vnode goes back onto the
free list when the file is closed.  If I understand things correctly
the vnode can then be recycled if there is the need for another file
(I know the vnodes linger around but at some point they start getting
recycled).  This means that if you open the first file again you get a
filehandle with a new generation number which will not match the list.

2) Generation numbers do wrap around, eventually.

>Also, what might be better is if the program included an id number. Stick
>the id number in a seperate ELF section, and you're fine. Make it kinda
>big, like 16 bytes or 32 bytes, and you shouldn't need to worry about

I am not sure what this will do.  To my mind dev/inode pairs give me
an exact location of the file on the machine.  Indexing on these does
mean that I have an automatic, unique locator with no modification to
any binaries.

>The big problem with either dev / inode pairs or filehandles is that they
>don't support restoring files from a backup. With keeping the id in the
>file, you can copy a binary and the copy still works (it's compared
>against the same key). restore'd programs work, as do just cp'ing the file
>somewhere else.

Ummmmm I would not expect that you would be restoring files in this
sort of security mode ;-)  Your point is valid but in the context that
the machine is running in I do not believe it to be an issue.
Especially considering that what I am doing may make the signed files
immutable which will cause the restore a modicum of grief :-)

Brett Lymn, Computer Systems Administrator, British Aerospace Australia