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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
