lkml.org 
[lkml]   [2004]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Encrypted Filesystem
Ah, can someone explain why encrypted loopback doesn't solve this?

JLC

On Tue, Jan 27, 2004 at 05:01:54PM -0500, Jan Harkes wrote:
> On Tue, Jan 27, 2004 at 12:43:21AM +0000, Adam Sampson wrote:
> > Michael A Halcrow <mahalcro@us.ibm.com> writes:
> >
> > > - Userland filesystem-based (EncFS+FUSE, CryptoFS+LUFS)
> >
> > Going off on a tangent...
> >
> > There are all sorts of potentially-interesting things that could be
> > done if Linux had a userspace filesystem mechanism included in the
> > standard kernel -- as well as encryption, there's also network
> > filesystems, various sorts of specialised caching (such as Zero
> > Install), automounter-like systems, prototyping and so on.
> >
> > Is there a technical reason that none of the userspace filesystem
> > layers have been included in the stock kernel, or is it just that
> > nobody's submitted any of them for inclusion yet?
>
> Ehh, Coda's kernel module does just that. It is used by the userspace
> cache manager of the Coda Distributed File System.
>
> http://www.coda.cs.cmu.edu/
>
> But several other projects seem to be using it,
>
> http://uservfs.sourceforge.net/
> http://dav.sourceforge.net/
>
> The interface to userspace a bit clumsy to work with, but there are
> kernel modules for FreeBSD/NetBSD/Solaris and an experimental one for
> Windows 2000/NT/XP, which makes any significant changes a bit of a pain.
>
> It does have it's pecularities, reads and writes are not passed up to
> userspace, only the open and close VFS calls. This makes the module
> reasonably quite simple as it doesn't have to deal with VM issues and it
> isn't susceptible to deadlocks,
>
> app wants to read data from a file ->
> userspace application requires memory allocation to provide this data ->
> VM tries to write out dirty data associated with the Coda mountpoint ==
> deadlock
>
> So whole file caching keeps the kernel module more portable and
> simplifies the userspace code. But it makes things like streaming
> reads/writes or quotas impossible. If you want to provide encryption
> there you would have to store an unencrypted copy of every open file
> somewhere on disk or in ramfs/tmpfs and incur the cost of (de)crypting
> (and (de)compressing) whenever it is opened or closed.
>
> Jan
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/

--
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:00    [from the cache]
©2003-2011 Jasper Spaans