[pkg-apparmor] Bug#782700: Bug#782700: Bug#782700: Please drop $remote_fs init.d dependency to allow running early

[intrigeri]

Hi,

Seth Arnold wrote (04 May 2015 18:58:10 GMT) :
> On Sun, May 03, 2015 at 01:32:48PM +0200, intrigeri wrote:
>> I see xargs used for a few different purposes in
>> debian/lib/apparmor/functions:
>> 
>> * when compiling the policy from scratch, e.g. on Live systems: [...]

> Having the parser handle its own parallelism has been on our backburner
> for a long time; calling the parser once per directory with profiles is
> the end goal, e.g. apparmor_parser --replace /etc/apparmor.d/
> (This works now, just without DTRT parallelism.)

That would be awesome. Are there currently any resources allocated to
implement that in a known timeframe? (No pressure intended, I'm just
trying to gather all the information we need to decide what's the best
strategy to handle the problem at hand.)

> The "exact same kernel" has been relaxed recently, either --match-string
> or --features-file or both ought to let a new-enough parser generate
> "correct" policy for a given target kernel using any other kernel. This
> could allow precompiling on the build hosts.

Thanks, this is good to know and I'll look into using it soon!

[Now getting slightly off-topic, at least Martin won't care I guess:

Regarding --match-string: in AppArmor 2.9.2, I see some rough
documentation for --match-string in apparmor_parser(8), and an example
value in parser.conf. I must say it's a bit too little for me to
understand how exactly I could use it.

Regarding --features-file: I see it roughly documented in the output
of apparmor_parser --help (but it's not documented in the manpage).
I've also found examples in parser/tst/features_files/* in the source
tree. I think I understand how a features file format matches the
content of /sys/kernel/security/apparmor/features/.

I'll try these things out and report bugs wrt. the perceived lack of
documentation, if needed.]

>> * in clear_cache(), [...]

> Recent gnu find supports -delete and avoids the fork()/exec() entirely.

Of course, thanks! /me blushes :)

Cheers,
-- 
intrigeri