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.
