Couple of points here.
First of all, have you considered trying to do this as a stacking
filesystem? Talk to the Intermezzo and Luster folks; they've gotten
quite good at stacking their value-added filesystem on top ext2/3.
This avoids code duplication, since now you don't have to track bug
fixes in the core ext2/3 code. It also enforces functional
separation, and should your filesystem smaller and easier to maintain.
It also means that you can potentially use your code to provide crypto
services to other filesystems besides just ext3.
Secondly, the really critical question is key management. What
happens if the user gets the key wrong? Will he/she know? Or will
they just get garbage if the read from the file, and be able to trash
the file if they write to the file with the incorrect key? Using some
kind of key-ID and some way of validating that the key is correct
before the user does start accessing files would probably be a really
good idea.
Finally, if you do want to allocate some additional fields in the ext2
inode, superblock, etc., please coordinate with me, so we can avoid
conflicts as much as possible. Thanks!!
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/