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
