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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
