On 19.05.2017 13:13, Guido Günther wrote: > 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@xxxxxxxxxxx> 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=c726af2d5a2248f0dad01201b2fc5231fbd4c20f >> [2]: >> http://libvirt.org/git/?p=libvirt.git;a=commit;h=cedd2ab28262db62976b351dbf2a0f8d9f88ca9e > > 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. Ok, I think we got the drift but need more time to ponder about that. Christian created a tracking bug for us and I move it to the needs-more-thinking section. -Stefan > > Cheers, > -- Guido >
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
