linux-ext4 - Re: xattr corruption issue on ext2fs generated filesystems

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] [day] [month] [year] [list]

Date:	Tue, 16 Feb 2016 23:35:43 -0800
From:	Darren Hart <dvhart@...radead.org>
To:	"Darrick J. Wong" <darrick.wong@...cle.com>
Cc:	Richard Purdie <richard.purdie@...uxfoundation.org>,
	Darren Hart <dvhart@...ux.intel.com>,
	linux-ext4@...r.kernel.org, Ted Ts'o <tytso@....edu>
Subject: Re: xattr corruption issue on ext2fs generated filesystems

On Sat, Feb 13, 2016 at 02:34:59PM -0800, Darrick J. Wong wrote:
> On Sat, Feb 13, 2016 at 01:29:55PM -0800, Darrick J. Wong wrote:
> > On Wed, Feb 10, 2016 at 10:20:52AM -0800, Darren Hart wrote:
> > > On Sat, 2016-02-06 at 11:23 +0000, Richard Purdie wrote:
> > > > I'm using the -d option of mke2fs to construct a filesystem, I'm
> > > > seeing
> > > > that some xattrs are being corrupted. The filesystem builds with no
> > > > errors but when mounted by the kernel, I see errors like
> > > > "security.ima:
> > > > No such attribute". The strace from such a failure is:
> > > 
> > > 
> > > Interesting. +Ted and +Darrick who helped us merge the -d argument
> > > originally.
> > > 
> > > 
> > > > mmap(NULL, 26258, PROT_READ, MAP_SHARED, 3, 0) = 0x7fdb36a8c000
> > > > close(3)                    = 0
> > > > getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=64*1024}) = 0
> > > > lstat("mnt/foobar", {st_mode=S_IFREG|0755, st_size=1, ...}) = 0
> > > > listxattr("mnt/foobar", NULL, 0) = 30
> > > > listxattr("mnt/foobar", "security.SMACK64\0security.ima\0", 256) = 30
> > > > getxattr("mnt/foobar", "security.SMACK64", 0x0, 0) = 1
> > > > getxattr("mnt/foobar", "security.SMACK64", "_", 256) = 1
> > > > fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 13), ...}) = 0
> > > > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> > > > 0) = 0x7fdb36a8b000
> > > > write(1, "# file: mnt/foobar\n", 19# file: mnt/foobar) = 19
> > > > write(1, "security.SMACK64=\"_\"\n", 21security.SMACK64="_") = 21
> > > > getxattr("mnt/foobar", "security.ima", 0x0, 0) = -1 ENODATA (No data
> > > > available)
> > > > write(2, "mnt/foobar: ", 12mnt/foobar: ) = 12
> > > > write(2, "security.ima: No such attribute\n", 32security.ima: No such
> > > > attribute) = 32= 32
> > 
> > Aha, you're right, the trick is that EAs in an external block have to be sorted
> > by index number, then by strlen(name), and then by strcmp(name).  Unlike inode
> > attributes, which can be in any order.
> > 
> > e2fsprogs inserts them in whatever order you happened to set them, which is
> > whatever order llistxattr provides them.
> > 
> > So, Mr. Purdie's is correct -- attr_compare needs to do more work, but it needs
> > to grab the index number and the suffix text (via find_ea_index()) and
> > replicate the same comparison operators as the kernel code.
> > 
> > (Not sure why we bother to sort the keys in the xattr block since there can
> > only be one block, but whatever...)
> 
> A patch to (I hope) fix this issue will appear shortly as patch #9 in
> my e2fsprogs patchbomb.  When it appears, can you please give it a spin?

Thank you very much Darrick!

-- 
Darren Hart
Intel Open Source Technology Center
--
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