On 11/21/19 3:31 PM, Peter Krempa wrote:
On Thu, Nov 21, 2019 at 14:02:49 +0100, Michal Privoznik wrote:
> On 11/20/19 3:22 PM, Peter Krempa wrote:
>>
New commit message:
qemuProcessStop: Remove image metadata for running mirror jobs
If user starts a blockcommit or a blockcopy then we modify access
for qemu on both images and leave it like that until pivot is
executed. So far so good. Problem is, if user instead of issuing
pivot (where we would modify the access again so that the state
before the job is restored) calls destroy on the domain or if
qemu dies whilst executing the block job. In this case we don't
ever clear the access we granted at the beginning. To fix this,
maybe a bit harsh approach is used, but it works: after all
labels were restored (that is after qemuSecurityRestoreAllLabel()
was called), we iterate over each disk in the domain and remove
XATTRs from the whole backing chain and also from any file the
disk is being mirrored to.
This would have been done at the time of pivot, but it isn't
because user decided to kill the domain instead. If we don't do
this and leave some XATTRs behind the domain might be unable to
start.
Also, secdriver can't do this because it doesn't know if there is
any job running. It's outside of its scope - the hypervisor
driver is responsible for calling secdriver's APIs.
Moreover, this is safe to call because we don't remember labels
for any member of a backing chain instead of the top layer. But
that one was restored in qemuSecurityRestoreAllLabel() call done
earlier. Therefore, not only we don't remember labels (and thus
this is basically a NOP for other images in the backing chain) it
is also safe to call this when no blockjob was started in the
first place, or if some parts of the backing chain are shared
with some other domains - this is NOP, unless a block job is
active at the time of domain destroy.
https://bugzilla.redhat.com/show_bug.cgi?id=1741456#c19
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
Michal