Hi Fabian! Fabian Grünbichler: > is there a particular reason for not putting this into the (included by > default) /usr/share/apparmor, but into parser.conf directly?
Does "this" refers to the features file itself or to the features-file= directive? What do you mean with /usr/share/apparmor being "included by default"? I wonder if there's a misunderstanding here. > this makes life of admins / downstreams using a newer kernel / policy / > feature set unnecessarily harder, as there is no way to override this > features-file config directive now besides > - messing with an apparmor-owned config file (possible for an admin, not > really an option for a derivative/downstream) > - re-building the apparmor package (lots of effort for overriding a > single config line) 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 :) > putting it into /usr/share/apparmor would allow drop-in replacement by > other packages and have the same net effect on stock Debian systems, at > least if I understood the terse parser.conf comments and apparmor_parser > man page correctly ;) I see. Now, local admins may want to modify their parser configuration, and the only way we currently have to allow them to do it is to ship parser.conf as a conffile in /etc. 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? > (thanks a lot for working hard on getting AA to work OOTB in Debian BTW > - long overdue and really looking forward to it!) Thank you :) Cheers, -- intrigeri