[apparmor] Bug#735470: Fwd: Bug#735470: Could be implemented centrally with a dpkg trigger instead of requiring every package shipping an apparmor file to use dh_apparmor

[John Johansen]

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.