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
