The libvirt_recover_xattrs.sh tool hangs when run. When no flags
are provided OPTIND is 1, so the loop expands to 'shift 0' which
has not effect. Rewrite to just loop over $@ instead which involves
less cleverness.
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The libvirt_recover_xattrs.sh script can be used to remove stale
XATTRs that were left behind by secdrivers (which should happen
only if there's an imbalance between set and restore calls).
Anyway, the script has '-n' switch which is supposed to perform
just a dry run, i.e. just to report which files have XATTRs set
without any attempt to remove them.
But, when rewriting the script a few months ago a typo was
introduced which made the script report no files even if there
were files with XATTRs.
Fixes: 5377177f80
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Loop for multiple PATH arguments to support shell pattern expansion.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In some cases you want to fix a certain directory while you don't really
care whether there are other VMs running. Add a option to disable the
check.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Linux and FreeBSD have different prefix. In the current state we've
tried to reset the labels for both systems which resulted in errors like
this:
Fixing /tmp/bitmaps2.qcow2
setfattr: /tmp/bitmaps2.qcow2: Operation not supported
setfattr: /tmp/bitmaps2.qcow2: Operation not supported
setfattr: /tmp/bitmaps2.qcow2: Operation not supported
setfattr: /tmp/bitmaps2.qcow2: Operation not supported
setfattr: /tmp/bitmaps2.qcow2: Operation not supported
setfattr: /tmp/bitmaps2.qcow2: Operation not supported
The 6 failed 'setfattrs' correspond to the wrong prefix.
Select the correct prefix based on the kernel name and modify the code
appropriately.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
It may happen that we leave some XATTRs behind. For instance, on
a sudden power loss, the host just shuts down without calling
restore on domain paths. This creates a problem, because when the
host starts up again, the XATTRs are there but they don't reflect
the true state and this may result in libvirt denying start of a
domain.
To solve this, save a unique timestamp (host boot time) among
with our XATTRs.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1741140
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Firstly, there's no reason to enumerate all XATTRs since they
differ only in the prefix and we can construct them in a loop.
Secondly, and more importantly, the script was still looking for
just one prefix "trusted.libvirt.security" even on FreeBSD.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Our code is not bug free. The refcounting I introduced will
almost certainly not work in some use cases. Provide a script
that will remove all the XATTRs set by libvirt so that it can
start cleanly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
