Recent changes and apparmor policy loads

[Zygmunt Krynicki]

On wto, 2016-04-12 at 22:25 -0500, Jamie Strandboge wrote:
> On Wed, 2016-04-13 at 01:48 +0200, Zygmunt Krynicki wrote:
> > 
> > > 
> > > 
> > > This was caused by the recent path renames. Tyler Hicks is
> > > preparing an apparmor upload for this.
> > Thanks for finding and fixing this.
> FYI, thanks to Tyler, this is now in xenial-proposed and making its
> way through
> proposed migration.
> 
> > 
> > On wto, 2016-04-12 at 16:42 -0500, Jamie Strandboge wrote:
> > > 
> > >  * https://bugs.launchpad.net/snappy/+bug/1569581 - snapd no
> > > longer
> > > detects 
> > >    apparmor changes on upgrade. This was caused by the removal of
> > > a
> > > check. I'm
> > >    not sure if interfaces is intended to handle this, but I don't
> > > think they
> > >    will properly in their current form and I'm not sure how they
> > > could handle
> > >    parser changes
> > Interfaces will handle that. As snapd starts up it will ensure that
> > all
> > the apps the the expected profile and if needed, reload any changed
> > profiles.
> > 
> IIRC, snappy is not currently doing an apparmor_parser -p <profile>.
> For this to
> work with interfaces in the manner you described, apparmor_parser -p
> is needed
> to preprocess the profile so it will expand all the #include'd rules
> in the
> policy and therefore the interfaces code would be able to detect
> apparmor
> abstractions changes, but I don't think interfaces does this today.
> Please
> correct me if I'm wrong. (Note apparmor_parser -p is not a recompile
> and is
> fast). We can discuss this on IRC.

I understand now. I will make sure this is handled.

> > 
> > Can you expand on the problem of parser changes?
> If there is a parser change that causes the profile to compile
> differently (ie,
> the cache/what is loaded into the kernel is different with the same
> input). This
> doesn't happen often but is possible. I don't think you are going to
> want to be
> in the business of comparing caches otherwise you lose all the
> benefits of
> caching, which was why we had the previous check. We can also discuss
> options
> for this on IRC.

Ack

Thanks for rising both issues!

Best regards
ZK