I'm going to handle these out of order, since 2) seems to be the
problematic case.

> 2) add space in
> the file handle to indicate which export point a file handle came from,
Ok, and for two hard links to the same file in incompatibly exported
subtrees, you end up either:
- choosing which of the export points to indicate in the file handle
OR
- creating two distinct file handles for the same file (one for each link)
  as I mentioned before

> The idea would be to 1) add some sort of long-term key that is passed in
> with each export. Something that is stable across boots.
> 3) add some sort of authentication so that we can tell if it's likely
> the file handle has not been tampered with. The thought is to do something
> so that it's harder to forge file handles.
You can certainly encrypt/decrypt file handles in the server, but all that
does is make it harder to spoof a file handle. It doesn't stop a client
from doing a "lookup .." or a replay attack using file handles captured on
the wire. Personally, I don't think it gets you enough to be worth the
overhead of the encryption/decryption, but???

If you combined this with something that stops "lookup .." across the
subtree boundary and also don't allow hard links across the subtree
boundary, then you've got something. (Exactly what you would have now by
making them separate file systems on the server.)

rick