Hi, Laurent Bigonville: > if a policy creator wants to modify the policy he might need to modify this > file as well same if a user is building his own kernel.
There's really no good reason why one would need to modify the default file in /usr: the features-file that the parser uses is configured in /etc/apparmor/parser.conf so if one wants to use a different one, they can point to their own features-file (stored wherever they want) instead of the default one. > There seems to have no override mechanism here that meas that if > anybody has modified the features file now that you move that file > to /usr it means that the changes will completely be ignored Right. Now, that file has been there (in testing/sid only) for less than 1.5 months so I doubt there's anyone who does advanced enough AppArmor things to modify that file but does not follow our discussion channels and would therefore be surprised by this move. I've considered documenting this in NEWS.Debian but decided against spamming everyone only to better support a use case I believe does not exist (and really, anyone doing this kind of advanced AppArmor things on testing/sid has all the skills needed to recover from the breakage in the unlikely event that any happened). > (leading to possible boot failures). I'm not concerned about it. I doubt we ship any policy that can break the boot if loaded under an unexpected feature set but I did not check. FWIW in the years I've been using AppArmor on dozens of systems, I've never seen it break my boot, and I can't recall any such bug report in Debian so far. I guess that's an advantage that comes with our current tiny AppArmor policy coverage (that you've pointed out elsewhere). Thanks for the feedback!