On Wed, Dec 06, 2017 at 03:28:03PM +0100, intrigeri wrote: > Hi, > > I'll first clarify because it seems to me you're using the same word > with very different meanings in a comparison: > > Fabian Grünbichler: > > TL;DR: while pinning the features prevents breakage for people using > > AA who install a more recent kernel from backports, > > In this case, "breakage" == application stops working after installing > a newer kernel. > > > it potentially breaks systems using a custom/backports/newer kernel > > and AA profiles requiring features not supported by the pinned 4.9 > > feature set. > > In this case, "breaks" == the AppArmor confinement becomes weaker, > but the application keeps working.
not the case for all scenarios unfortunately. LXC containers using the upstream profiles (and a kernel supporting the needed features) don't start anymore: apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 profile="/usr/bin/lxc-start" name="/" pid=21550 comm="lxc-start" flags="rw, rslave" the profile[1] contains: mount options=(rw, make-slave) -> **, mount options=(rw, make-rslave) -> **, the same profile and container worked fine without feature pinning. this is not specific to certain container configurations either AFAICT. > > > since > > both the AA config file itself and the feature set file are conffiles, > > overriding is not easily possible without conffile modification. > > Right. Sorry I did not think about this Debian derivative use case. > while it is sometimes cumbersome to work around such issues, it is understandable to not have them on one's radar, especially if the upstream software does not provide an easy way to extend configuration files. > > I'll of course defer to intrigeri and the release team on whether to go > > ahead as-is, include the patch to allow easier overriding or postpone > > the apparmor stable update until the next cycle to allow for further > > discussion. > > I slightly prefer fixing ASAP a non-default use case I want to support > in Debian (that's what we did in s-p-u already), even if it makes > a derivative's life slightly harder temporarily when using an much > more non-default configuration. I would understand if the release team > prefers to delay this update to a future point release though. > obviously with my downstream hat on, I'd strongly prefer not having to carry apparmor packages for the remainder of Stretch ;) but if necessary we will take this route, and work together with upstream and you to get more easily overridden apparmor config including feature pinning in time for Buster, hopefully eliminating the need for forked apparmor packages. > But I can live with both approaches. The vast majority of Stretch > users are not affected by either of the problems described > above anyway. I am glad we noticed it before the point release went live! 1: https://github.com/lxc/lxc/blob/d680929bbc07e399ceaf8954c2059bd788905fc7/config/apparmor/abstractions/start-container
