linux-ext4 - Re: [PATCH 2/2] misc: Add fuse2fs, a FUSE server for e2fsprogs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120217151840.GE19606@thunk.org>
Date:	Fri, 17 Feb 2012 10:18:40 -0500
From:	Ted Ts'o <tytso@....edu>
To:	"Darrick J. Wong" <djwong@...ibm.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 2/2] misc: Add fuse2fs, a FUSE server for e2fsprogs

On Sat, Jan 07, 2012 at 12:55:35AM -0800, Darrick J. Wong wrote:
> This is the initial implementation of a FUSE server based on e2fsprogs.  The
> point of this program is to enable ext4 to run on any OS that FUSE supports
> (and doesn't already have a native driver), such as MacOS X, BSDs, and Windows.
> The code requires FUSE API v28, which is available in Linux fuse and osxfuse
> releases that are available as of January 2012.
> 
> Signed-off-by: Darrick J. Wong <djwong@...ibm.com>

So my system supports up to FUSE API v26 (this is an Ubuntu 10.04
system; the same should be true for RHEL 5 and RHEL 6 as I understand
things, since fuse 2.7 and 2.8 both stayed at the same API level).
Nothing blew up when I built fuse2fs with this version of fuse, and
when I mounted it, it (mostly) seemed to work --- except it corrupted
some files randomly, and ultimately corrupted the file system itself.

I don't know yet whether this is due to the FUSE API mismatch, or some
bugs in fuse2fs, but either way, this is scary, especially since all
of the failures were silent until the data and file system corruption
happened.

Do you know why the code requires FUSE API v28, and not FUSE API v26,
and is there an explicit way (either at run time or at compile time)
to determine if there is an API mismatch?

I'm going to hold off on including this patch for now, for the obvious
reasons....

Thanks,

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html