linux-kernel - Re: 2.6.19 -mm merge plans (ecryptfs)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20060922165331.GB3186@us.ibm.com>
Date:	Fri, 22 Sep 2006 11:53:31 -0500
From:	Michael Halcrow <mhalcrow@...ibm.com>
To:	Andrew Morton <akpm@...l.org>
Cc:	Christoph Hellwig <hch@...radead.org>,
	linux-kernel@...r.kernel.org, Erez Zadok <ezk@...sunysb.edu>,
	Josef Sipek <jsipek@....cs.sunysb.edu>
Subject: Re: 2.6.19 -mm merge plans (ecryptfs)

On Fri, Sep 22, 2006 at 09:03:37AM -0700, Andrew Morton wrote:
> On Fri, 22 Sep 2006 15:42:33 +0100
> Christoph Hellwig <hch@...radead.org> wrote:
> 
> > > ecryptfs-versioning-fixes-tidy.patch
> > > 
> > >  Will fold into a single patch and will then merge.
> > 
> > Please add a
> > 
> > Not-Acked-By: Christoph Hellwig <hch@....de>
> > 
> > here as you don't seem to listen to any of the comments I had
> > against the current state and I want this clearly documented.
> 
> I thought everything got addressed, apart from
> 
>  - please split all the generic stackable filesystem passthorugh routines
>    into a separated stackfs layer, in a few files in fs/stackfs/ that
>    you depend on.  They'll get _GPL exported to all possible stackable
>    filesystem.  They'll need their own store underlying object helpers,
>    but that can be made to work by embedding the generic stackfs data
>    as first thing in the ecryptfs object.
> 
> which seemed rather a lot to ask.

A common framework that would be useful for all potential stackable
filesystems is indeed a major project in and of itself, and such a
thing right now would be premature. We need to see how code for other
stackable filesystems will look once it is actually in the
kernel. There is core behavior that differs between eCryptfs and
Unionfs -- for instance, how inodes are referenced. eCryptfs, in its
current form, can do just fine with referencing the internal inode
struct pointer, whereas Unionfs implements persistent inodes. Then
there are issues with readdir/filldir semantics, wherein Unionfs needs
a mechanism to implement whiteout operations. eCryptfs just has a
simple one-to-one VFS layer mapping, while Unionfs has to merge
several VFS mounts under it. The core *_info data structure diverge
quite a bit between the two. Right now, eCryptfs and Unionfs can get
by with a page-to-page mapping between the upper and lower files, but
that would not necessarily be the case for a compressing stacked
layer; the common framework would have to take that into
consideration.

Stacked filesystem authors are certainly interested in addressing
these sorts of issues, but an iterative strategy for solving them is
the most reasonable approach. The first step is to get at least two
stacked filesystems into the kernel (eCryptfs and Unionfs) and then
follow up with a series of patches to extract the common functionality
once we see somewhat finalized code bases for both.

Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/