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

[Stefan Bader]

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 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.


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
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170522/f1a949b4/attachment-0001.sig>