Re: [PATCH 0/13: eCryptfs] eCryptfs Patch Set

[Christoph Hellwig <hch@infradead.org>]

On Fri, Jul 07, 2006 at 01:22:09PM -0400, David Quigley wrote:
> This is actually an interesting thing. Due to certain issues, stackable
> file systems normally do not allow people to modify the lower level
> files from under the mounted stackable filesystem. Ideally you want to
> be able to view a stack and make changes at each level. This is possible
> but not without some changes to the kernel. If we go with the statement
> that you should not modify lower level files except through eCryptfs
> (which seams reasonable since its an encryption file system) then this
> is not needed. We do not need to pass the lock down to the lower file
> system since locking the upper level file is more than adequate. If we
> decide to make the changes to the kernel to allow for modifications at
> each layer of a stack then we do need this.

Getting locking right if you want to allow access from above and below
the stackable filesystems will be a pain.  Note that I can't see any
way to exclude direct access to the underlying filesystem in ecryptfs.

> > And a more general issue with implementing stackable filesystems:
> > 
> >   I think it's probably much better to not stack ontop of a part of the
> >   existing namespace but rather let ecryptfs mount the underlying filesystem
> >   internally using vfs_kern_mount.  This gets out of the way of possible
> >   lock order problems when doing namespace operation involving both the
> >   stacked and underlying filesystem aswell as allowing using a stackable
> >   filesystem as the root filesystem.
> > 
> 
> Could you actually explain this with an example? If it is what I think
> you mean then we did look into this and we had some concerns with it
> however I'll make sure its the same before we delve into it.

I don't think there's too much of example for the behaviour I want.

But lets explain it a little better:

 - The idea is to avoid having the underlying filesystem mounted in any
   public namespace.

 - Linux has the concept of mount points that only the kernel can use and
   that aren't visible to any public namespace.  They can be created using
   the *kern_mount family of APIs.

 - I suggest to use this API to mount the underlying filesystems from
   ecryptfs.  It will have a reference to the vfsmount * and thus all
   important data for the underlying filesystem.  Because it is the only
   user of that filesystem locking and other operations get a lot simpler.