> [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:
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:
chmod(0600 | oldperm)
And of course this must be done atomically on the file so this doesn't
get mixed up with other calls.
On Mon, 2003-10-27 at 04:26, Miklos Szeredi wrote:
> > 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)?
Sure, please do.
> Since the VFS checks the permissions before the open method is called,
> the open method simply should not recheck the permissions.
Ok, I did not know that VFS did its own permission checks before calling
open. That helps, since I can assume then that if the open call is
made, then it should just be a matter of figuring out to get it done
rather then deciding if it should be disallowed..