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
