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

Guido Günther agx at sigxcpu.org
Fri May 19 11:13:49 UTC 2017

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 at sigxcpu.org> 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.

 -- Guido

More information about the libvir-list mailing list