[apparmor] Bug#846966: [pkg-apparmor] Bug#846966: evince: Please make the AppArmor profile support merged-/usr systems

[intrigeri]

hi,

[adding the upstream AppArmor list to Cc]

Michael Biebl:
> Mind you, that I don't know how apparmor actually works.

That's fine :) I'm actually very happy to see you chime in and propose
interesting ideas!

> This is my idea basically: say you have a apparmor profile which
> contains /bin/foo.
> When that profile file is read by the apparmor profile parser, you check
> for symlinks in those paths.
> The parser notices on a merged user system that /bin is a path to
> /usr/bin, so it adds /bin/foo and /usr/bin/foo on the whitelist.

This would indeed avoid patching anything for things like merged-/usr,
/var/run and friends. The main problem I see with this approach is
that as a side-effect, it will create rules that overlap with other
parts of the policy, which causes various problems: 1. if such rules
have conflicting "x" modifiers, policy compilation will fail hard
(that's not theoretical: I've actualy hit such problems while
preparing the patches for merged-/usr); 2. automatic "let me fix the
policy you wrote on the fly" stuff tends to be harder to audit and
debug (which is the main reason why I decided against using the
existing AppArmor "alias" support to deal with merged-/usr).

Now, I wonder if there are more problems that would come with this
approach, that explain why it wasn't chosen. Or whether it's "just"
a matter of lacking time to implement it… in which case it likely
won't happen in time for Stretch, while merged-/usr will quite
possibly be the default in there, so it would be nice to have the
proposed patch applied :)

Cheers,
-- 
intrigeri