linux-ext4 - Re: test f_extent_htree fails on 1.44.3-rc1

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 27 Jun 2018 13:12:07 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Lukas Czerner <lczerner@...hat.com>
Cc:     linux-ext4@...r.kernel.org, adilger@...ger.ca
Subject: Re: test f_extent_htree fails on 1.44.3-rc1

On Wed, Jun 27, 2018 at 06:14:47PM +0200, Lukas Czerner wrote:
> Meanwhile I've created something as well. I am not yet ready to send it
> since I was going to review and create test for it. It has some more
> functionality

Sorry, I should have sent out my path last night.

Thanks for taking as stab at it, but it's a lot of code changes when
I'm trying to stablize things for a 1.44.3 release.  In fact, even if
we weren't at 1.44.3-rc1, this level of new functionality is something
that I'd want to save for 1.45.

I also wonder if we want to add this much flexibility/functionality,
that perhaps we should push it to an external file, since the main
people who would be using this are people who are building file
sytsems for IOT devices.  So it would probably be something that might
look like this:

[defaults]
	copy_xattrs = yes
	uid = 1000
	gid = 1000

[sources]
	root_dir = {
		pathname = test_appliance/etc
		copy_xattrs = no
		uid = 0
		gid = 0
	}
	application = {
		pathname = build
	}

[overrides]
	/usr/bin/sudo = {
		mode = 04755
		uid = 0
		uid = 0
		selinux_label = wizard_t
	}

... and since I'm not the target user of such feature, I'd really want
to recruit or consult with one of the people who had originally
proposed the mke2fs -d feature to see what they think.

One advantage of using the above syntax is we can reuse the parsing
code we already have in libsupport/profile.c, which we use for
mke2fs.conf and e2fsck.conf.

Oh, and I might want to take a look at what's in contrib/e2fsdroid.c
to see what other functionality the AOSP folks need/want, and see what
if any of it makes sense for us to support officially upstream.

What do folks think?

						- Ted