On 01/16/2014 03:03 PM, Kees Cook wrote: > On Thu, Jan 16, 2014 at 02:59:54PM -0800, John Johansen wrote: >> On 01/16/2014 02:57 PM, John Johansen wrote: >>> On 01/16/2014 02:49 PM, Kees Cook wrote: >>>> On Thu, Jan 16, 2014 at 07:37:04PM +0100, Didier 'OdyX' Raboud wrote: >>>>> Le jeudi, 16 janvier 2014 10.14:14, vous avez écrit : >>>>>> On Thu, Jan 16, 2014 at 11:11:22AM +0100, Didier 'OdyX' Raboud wrote: >>>>>>> As far as I understand deb-triggers' manpage, this can be enforced >>>>>>> using 'activate /etc/apparmor.d/', which will then make the trigger >>>>>>> run "at the start of the configure operation", which ensures >>>>>>> exactly what you want. >>>>>> >>>>>> Per-policy reloads must happen before a daemon restarts, so they >>>>>> cannot be triggers. >>>>> >>>>> Err… >>>>> >>>>> man deb-trigggers contradicts you, in my reading; an 'activate >>>>> /etc/apparmor.d' triggers' file in apparmor would make its action run >>>>> _before_ cups (which would have shipped /etc/apparmor.d/usr.sbin.cupsd) >>>>> would be 'configured' (hence its postinst run). >>>>> >>>>> Isn't it? >>>> >>>> Right, sorry, you are right, but my original observation stands: we should >>>> never reload all apparmor profiles when installing a single profile. Just >>>> the single profile should be reloaded. Otherwise we end up doing very >>>> CPU expensive work for no reason. The point of dh-apparmor is to reload a >>>> single profile, not all of them. Doing a trigger for all-profile reload >>>> isn't something we want. Think of the situation where someone has 5000 >>>> apache virtual host profiles and they update cups. We never want to wait >>>> for those 5000 to be reloaded when cups's profile is installed. Hence, >>>> dh_apparmor. >>>> >>> Is there a way for a trigger to notice which file was updated? >>> That way we could use a trigger. >>> >>> If not another option that comes to mind is we could add a new flag to the >>> parser that would say reload only if the cache is out of date. >>> >>> The trigger would have to still do work figuring out which cache files >>> are out of date but thats still better than reloading everything to the >>> kernel. >>> >> by trigger, I mean the parser/script called by the trigger. > > I can't remember -- does the parser do the right thing in the face of > included files timestamps? If so, yeah, this could work. > it has for the last couple years now.
-- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
