[pkg-apparmor] Bug#883682: don't install features-file as conffile for easier overriding

[Fabian Grünbichler]

Control: tags + patch

On Wed, Dec 06, 2017 at 11:31:45AM +0100, intrigeri wrote:
> Hi,
> 
> Fabian Grünbichler:
> > I am not sure whether the features file itself would really need to be a
> > conf file though, if it is already pointed to by a conf file directive?
> > putting the features file itself somewhere into /usr/share would at
> > least allow a sane divertion without having to touch the parser.conf as
> > an alternative solution to the one described below?
> 
> > modifications by the admin would still be easy (just point to a modified
> > copy of the features file), and modification by downstreams would be a
> > lot easier (just divert the features file) than currently..
> 
> Right. This looks like a good interim solution to me. Do you want to
> try to implement it in the packaging?

see attached patch. I didn't find a branch for the s-p-u upload (but
that might just be my non-existing bzr skills failing me), so it's based
on the upload's debian directory. it should apply cleanly to the
master/unstable branch as well.

for applying to master/unstable, an additional rm_conffile is probably a
good idea to decruft /etc/apparmor. for s-p-u/stable, I don't think it
would be necessary - the conffile has only been there in one upload to
s-p-u.

I decided to move the features file into /usr/share/apparmor-features
because /usr/share/apparmor is already the default include search path.
it would be possible to extend this further and e.g. provide multiple
features files for different (Debian) kernel versions, and symlink the
default one which is referenced in /etc/apparmor/parser.conf ?

it would be rather important for us to know whether you plan on applying
and including this for the point release on Sunday (or postpone the
feature pinning apparmor update until the next point release) - as
otherwise we'll have to repackage apparmor in our derivate without the
latest changes, and carry this delta (with all the associated extra
cost) until Buster at least. to make matters worse, Friday is a holiday
over here, so this decision will have to be made tomorrow morning UTC at
the latest. don't want to wakeup to >> 100k hosts not being able to
start their LXC containers on Monday because users upgraded to a Debian
point release over the weekend ;)

I am not sure whether we are the only derivative/downstream/.. affected
by this change, but it has the potential to break a lot of setups using
their own (more recent / patched to support more of AA) kernel and AA
profiles on top of Stretch.. so maybe it is an option to delay it for
one point release and figure out a better way to go forward without the
rush / with more advance notice to potentially affected users?

> 
> > intrigeri:
> >> Understood. Ideally parser.conf would be complemented by
> >> /etc/apparmor/parser.conf.d/*.conf, which could be sourced at the end
> >> of parser.conf somehow. And then we can ship the default parser.conf
> >> in /usr. TTBOMK we have no way to source such additional config
> >> drop-in snippets though. I suspect upstream would be happy to consider
> >> patches that add this feature :)
> 
> > yes, that would have been nice. alas, there is no such thing now, and
> > getting one in time for the upcoming point release is not really an
> > option.. maybe in time for buster?
> 
> >> If we had this drop-in snippet support for complementing the default
> >> parser.conf, then both your use case and that one would be supported
> >> nicely, right?
> 
> > yes.
> 
> Would you be willing to work on such a feature upstream so downstreams
> & derivatives have a cleaner (than diversion) way to address
> this problem?

that should be do-able, but I won't have time to take a closer look this
week.

> 
> Either way, can you please file a dedicated bug report so we track
> this issue elsewhere than on a bug that's going to be closed in
> a few days?

done.