Re: [libvirt] [PATCH 01/10] virt-aa-helper: Ask for no deny rule for readonly disk elements

On Fri, May 19, 2017 at 11:18:18AM +0200, Christian Ehrhardt wrote: > On Fri, May 19, 2017 at 10:03 AM, Guido Günther <agx(a)sigxcpu.org&gt; wrote: > >> But if we aim for a profile replace on blockcommit [1] the would't matter >> since the whole profile would get replaced, wouldn't it? >> > > Since this is based on [1][2] looping in Cédric here to share some old > explaiantions. > See especially [1] for some reasoning for 'R' in general. > > [1]: > http://libvirt.org/git/?p=libvirt.git;a=commit;h=c726af2d5a2248f0dad01201... > [2]: > http://libvirt.org/git/?p=libvirt.git;a=commit;h=cedd2ab28262db62976b351d... Let me try to explain why I don't consider this to be a proper fix: virsh blockcommit is invoked this leads to: 1.) qemuDomainBlockCommit -> 2.) qemuDomainDiskChainElementPrepare -> 3.) qemuSecuritySetImageLabel -> 4.) AppArmorSetSecurityImageLabel (triggers profile reload only) -> 5.) virt-aa-helper does the profile reload -> 6.) failure since the image has an explicit deny rule The path in question tries to fix this at 5.) by not adding a deny write rule at all but the place to fix this is 4.) since AppArmorSetSecurityImageLabel does not take the virStorageSourcePtr src element into account to create a virDomainDefPtr based on def that marks the image in question as 'rw' but "only" reloads the profile.

Cheers, -- Guido