[PATCH 1/3] eCryptfs: eCryptfs kernel module

[PATCH 1/3] eCryptfs: eCryptfs kernel module

[Phillip Hellewell]

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 <phillip@hellewell.homeip.net>
Signed off by: Michael Halcrow <mhalcrow@us.ibm.com>

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

-- 
Phillip Hellewell <phillip AT hellewell.homeip.net>

Re: [PATCH 1/3] eCryptfs: eCryptfs kernel module

[Greg KH]

On Wed, Jun 01, 2005 at 11:47:40PM -0600, Phillip Hellewell wrote:
> 
> 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

Re: [PATCH 1/3] eCryptfs: eCryptfs kernel module

[James Morris]

On Thu, 2 Jun 2005, Greg KH wrote:

> 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
-- 
James Morris
<jmorris@redhat.com>

Re: [PATCH 1/3] eCryptfs: eCryptfs kernel module

[Michael Halcrow]

On Thu, Jun 02, 2005 at 03:33:58AM -0400, James Morris wrote:
> 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

Re: [PATCH 1/3] eCryptfs: eCryptfs kernel module

[Greg KH]

On Thu, Jun 02, 2005 at 07:32:19AM -0500, Michael Halcrow wrote:
> 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

Re: [PATCH 1/3] eCryptfs: eCryptfs kernel module

[Michael Halcrow]

On Thu, Jun 02, 2005 at 12:33:03AM -0700, Greg KH wrote:
> 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

Re: [PATCH 1/3] eCryptfs: eCryptfs kernel module

[Greg KH]

On Thu, Jun 02, 2005 at 07:28:07AM -0500, Michael Halcrow wrote:
> On Thu, Jun 02, 2005 at 12:33:03AM -0700, Greg KH wrote:
> > 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

Re: [PATCH 1/3] eCryptfs: eCryptfs kernel module

[James Morris]

On Thu, 2 Jun 2005, Michael Halcrow wrote:

> On Thu, Jun 02, 2005 at 12:33:03AM -0700, Greg KH wrote:
> > 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
-- 
James Morris
<jmorris@redhat.com>