On 01.10.2014 11:04, Daniel P. Berrange wrote:
On Wed, Oct 01, 2014 at 10:30:58AM +0200, Stefan Bader wrote:
> This had been on the Debian package list before but its time to take
> this onwards. So the goal would be to have one set to rule them all
> (when using apparmor) and drop the seperate set of definitions which
> exist at least in the Ubuntu packaging.
>
> Right now the patch would be at a state which adds all missing files
> and rules to the current examples in libvirt and installs them when
> using --with-apparmor-profiles.
>
> One problem seems to be that some of the definitions might cause
> parse failures on certain versions of apparmor. I checked this morning
> and this looks a bit hairy. So some apparmor 2.8 versions potentially
> have issues, but not all apparmor 2.8 are the same (gah).
What versions of apparmour are present in the currently supported
versions of Debian & Ubuntu ?
The way release are handled in Ubuntu (once released there is usually no
backporting) we would have to worry less about supported releases. For the
Debian side I would think this is similar (correct me if I am wrong, please). So
it looks to me that right now this would be down to Debian having 2.8.0 in
unstable/testing and Ubuntu having 2.8.96~2652 in Utopic (with the same version
in Debian experimental).
Right now I would expect it to boil down to those two. But I suppose the parser
can change again and so there might be a similar situation in the future.
-Stefan
> I could imagine (but John, we really could use some guidance here ;))
> that at least some changes could be related to version 2.8.95~2430:
>
> + debian/patches/mediate-signals.patch,
> debian/patches/change-signal-syntax.patch: Parse signal rules with
> apparmor_parser. See the apparmor.d(5) man page for syntax details.
> + debian/patches/change-ptrace-syntax.patch,
> debian/patches/mediate-ptrace.patch: Parse ptrace rules with
> apparmor_parser. See the apparmor.d(5) man page for syntax details.
>
> But, regardless of the when, the apparmor rules maybe need a way to handle
> versioned features of the parser. One proposal was to comment out problematic
> rules and allow the packager to re-enable things. Maybe going one step
> further and have some pre-processing that handles version based sections
> (like #if (APPARMOR_VERSION >= xxx)).
I think it would be pretty reasonable to rename the files in have '.in'
suffixes, and then have a build script that expands 'if APPARMOR_VERSION'
conditionals to generate the final file.
Regards,
Daniel