eCryptfs: eCryptfs kernel module
PATCH 1/3 eCryptfs: eCryptfs kernel module
This is the first in a series of 3 patches for the eCryptfs kernel module.
eCryptfs is a cryptographic filesystem that stacks on top of other filesystems. A very early version of it was presented last year at OLS, and the current version will be presented again at this year's OLS. It is currently in an EXPERIMENTAL and BROKEN state (i.e., it will build and run, but there is at least one memory leak that causes a problem when a several dozen file open/read/write operations are performed). It requires userspace components to run, which can be obtained via CVS from the eCryptfs project site:
http://sourceforge.net/projects/ecryptfs
The README file from CVS explains how to get it up and running with both passphrase and public key (PKI) operation modes.
While eCryptfs is functional, there is a significant amount of work yet to be done; a perusal of the source will reveal that there is a lot of low-hanging fruit/trivial fixes (David Howells: we promise that using your keyring correctly is near the top of the list, right after we get these memory leaks resolved). It derives from cryptfs, which is a cryptographic filesystem instantiated by Erez Zadok's stackable filesystem framework, FiST. We are aware that there are some extant bugs in the version of cryptfs that we built off of; as those are made known, we will be applying fixes. In the meantime, we would like the eCryptfs kernel module to be merged into the mainline kernel. We are open to suggestions and commentary on the general design of the filesystem, and bugfixes are always welcome too.
Signed off by: Phillip Hellewell <[email protected]> Signed off by: Michael Halcrow <[email protected]>
This first patch is somewhat large (45K), so here is a link:
http://ecryptfs.sourceforge.net/patches/patch-2.6.12-rc4-mm2-ecryptfs-1_of_3.diff.gz
Signature · 1 line
Phillip Hellewell <phillip AT hellewell.homeip.net>
Quoted 11 lines · Phillip Hellewell
While eCryptfs is functional, there is a significant amount of work yet to be done; a perusal of the source will reveal that there is a lot of low-hanging fruit/trivial fixes (David Howells: we promise that using your keyring correctly is near the top of the list, right after we get these memory leaks resolved). It derives from cryptfs, which is a cryptographic filesystem instantiated by Erez Zadok's stackable filesystem framework, FiST. We are aware that there are some extant bugs in the version of cryptfs that we built off of; as those are made known, we will be applying fixes. In the meantime, we would like the eCryptfs kernel module to be merged into the mainline kernel.
Why not fix up the stuff that you know needs to be fixed? It should not be merged until then at the least.
Good luck,
greg k-h
Quoted 2 lines · Greg KH
Why not fix up the stuff that you know needs to be fixed? It should not be merged until then at the least.
After that, please read Documentation/CodingStyle,
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt,
http://linux.yyz.us/patch-format.html
Break up your patch and send it in logical chunks, so it can be reviewed easily.
- James
Signature · 2 lines
James Morris <[email protected]>
Quoted 2 lines · James Morris
Break up your patch and send it in logical chunks, so it can be reviewed easily.
In discussions with some developers from JFS and CIFS, it was suggested that the best thing would be to submit one patch with the whole contents of the fs/ecryptfs directory, since it is a new filesystem with no modifications to existing code. What sort of logical chunks would you consider to be appropriate? Separate patches for each file (inode.c, file.c, super.c, etc.), which represent sets of functions for each major VFS object?
Thanks,
Mike
Quoted 4 lines · Michael Halcrow
What sort of
logical chunks would you consider to be appropriate? Separate patches for each file (inode.c,file.c,super.c, etc.), which represent sets of functions for each major VFS object?
Yes.
thanks,
greg k-h
Quoted 2 lines · Greg KH
Why not fix up the stuff that you know needs to be fixed? It should not be merged until then at the least.
We'll keep plugging away; note that all this could take several months (there are currently about 160 TODO items in the code base, plus several more features to flesh out), and in the meantime, we would like some general commentary from the community so we don't wind up pouring time and effort in the wrong direction.
Thanks,
Mike
Quoted 9 lines · Michael Halcrow
Quoted 2 lines · Greg KH
Why not fix up the stuff that you know needs to be fixed? It should not be merged until then at the least.
We'll keep plugging away; note that all this could take several months (there are currently about 160 TODO items in the code base, plus several more features to flesh out), and in the meantime, we would like some general commentary from the community so we don't wind up pouring time and effort in the wrong direction.
That's fine, but you asked for it to be accepted now, and yet you pointed out major issues remaining. You can see how I would be confused :)
thanks,
greg k-h
Quoted 9 lines · Michael Halcrow
Quoted 2 lines · Greg KH
Why not fix up the stuff that you know needs to be fixed? It should not be merged until then at the least.
We'll keep plugging away; note that all this could take several months (there are currently about 160 TODO items in the code base, plus several more features to flesh out), and in the meantime, we would like some general commentary from the community so we don't wind up pouring time and effort in the wrong direction.
Posting it here for comments should generate commentary, but it will also help greatly if you format the patches properly, closely follow the kernel coding style and include the patches in your emails. The closer it looks to be ready to apply to a real kernel tree, the more people will take notice.
You can also ask for help with development, or if it's a really compelling project, people may just dive in anyway.
- James
Signature · 2 lines
James Morris <[email protected]>