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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 28 Jun 2018 08:55:34 +0200
From:   Lukas Czerner <lczerner@...hat.com>
To:     "Theodore Y. Ts'o" <tytso@....edu>
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 01:12:07PM -0400, Theodore Y. Ts'o wrote:
> 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.

Understandable. I didn't really like the idea of adding separate options
for that so I changed the -d parameter.

But you're right, it's a bit much for rc1. How about just changing the
test to skip if we find extended attributes on the source directory a
move this to after the 1.44.3 is release ?

> 
> 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.

I'm not the target user either, but the -d options scheme I proposed
is not really in conflict with supporting external config file as well.

-Lukas

> 
> 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