On Tue, 15 Jun 1999, Brett Lymn wrote:

> 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.

You're describing the capability identifier, v_id. Generation numbers are
kept in fs-specific structures, and stored on disk. For instance, see
sys/ufs/dinode.h, and look at di_gen in struct dinode. These numbers have
a life cycle similar to what you describe, but they get incrimented when
an inode gets reused. i.e. when someone's deleted the file off of disk
and then reused the inode.

Also, file handles are a much more canonical way of identifying a file. If
you use dev/inode, you're stuck with ffs. Filehandles give you a level of
abstraction/generalization.

As an aside, the data migration system I've been working on used dev/inode
pairs earlier, and we've moved to file handles. So all of these questions
are fresh in my mind. :-)

> 2) Generation numbers do wrap around, eventually.

Yes, but inodes will get re-used much sooner than that. :-)

> >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
> >duplicates.
> 
> 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.

True, you don't modify binaries. And in some cases, that could be a really
big deal.

But it strikes me that it will confuse people in a multi-user system. For
instance, you can't copy a working binary and have the copy work.

> >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 :-)

For a locked-down, no users server, your ideas will probably be fine. But
from watching the servers around here, I think there are a lot of signed
binaries other than just the lock-down&leave server. It'd be cool if our
signed binary support could serve these applications too.

For instance, don't make signing dependent on run level, make it a sysctl.
And maybe add signature checking as a mount-point option. For multi-user
servers, it'd make a lot of sense to sign all the binaries in / and in
/usr, while leaving /home's binaries runnable as-is.

Take care,

Bill