[Avf-fuse-dev] Re: [AVFS] encrypted filesystem for fuse (release)

[<Mik...@et...>]

> [Resending this mail, since I was unsubscribed to the list when I sent
> it the first time]

Actually there is a list for FUSE development: avf-fuse-dev (CC-d).

> I have an encrypted filesystem for FUSE available here:
> http://pobox.com/~vgough/encfs.html

Can I add this to the list of projects using FUSE (fuse/Filesystems)?

> There is one known issue that relates to FUSE.  Basically the encfs
> filesystem is a pass-through to an underlying filesystem, except it
> changes names and file data.   When I untar a file with read-only files
> in it, then tar tells me it can't open the file for writing.
> 
> Tracing through printf data and using strace to show tar working, what
> happens is that tar opens a file like this:
> 
> open("foo/bar", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0444)
> 
> Ie, it creates a file in write-only mode with 0444 permissions.  FUSE
> turns that into two separate calls:
> 
> 1. mknod -- create "foo/bar" with permission 0444
> 2. open -- open "foo/bar" as O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE

Oh, those wonderful open semantics!

> Now of course the file is read-only at the time of the open call, so the
> open fails.  I've been thinking about caching mknod calls to get around
> this, but I don't see any way for me to distinguish between what was
> originally an open/create of a read-only file and a create of a
> read-only file with a later attempt to open it for write (which should
> be denied).
> 
> Any ideas?

Since the VFS checks the permissions before the open method is called,
the open method simply should not recheck the permissions.  I realize
that this is ugly, but I see no alternative.

So open could be implemented somthing like this:

   stat()
   chmod(0600 | oldperm)
   open()
   chmod(oldperm)

And of course this must be done atomically on the file so this doesn't
get mixed up with other calls.

Miklos