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

Christoph Hellwig
2006-07-08T17:21:25Z

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.