Re: [libvirt] [PATCH/RFC] Add missing delta from Ubuntu to apparmor profiles

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.