When iterating over list of paths/disk sources to relabel it may
happen that the process fails at some point. In that case, for
the sake of keeping seclabel refcount (stored in XATTRs) in sync
with reality we have to perform rollback. However, if that fails
too the only thing we can do is warn user.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
src/security/security_dac.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/src/security/security_dac.c b/src/security/security_dac.c
index f01d0b4732..7be555903d 100644
--- a/src/security/security_dac.c
+++ b/src/security/security_dac.c
@@ -229,7 +229,6 @@ virSecurityDACTransactionRun(pid_t pid ATTRIBUTE_UNUSED,
for (i = 0; i < list->nItems; i++) {
virSecurityDACChownItemPtr item = list->items[i];
- /* TODO Implement rollback */
if (!item->restore) {
rv = virSecurityDACSetOwnership(list->manager,
item->src,
@@ -246,6 +245,19 @@ virSecurityDACTransactionRun(pid_t pid ATTRIBUTE_UNUSED,
break;
}
+ for (; rv < 0 && i > 0; i--) {
+ virSecurityDACChownItemPtr item = list->items[i - 1];
+
+ if (!item->restore) {
+ virSecurityDACRestoreFileLabelInternal(list->manager,
+ item->src,
+ item->path);
+ } else {
+ VIR_WARN("Ignoring failed restore attempt on %s",
+ NULLSTR(item->src ? item->src->path : item->path));
+ }
+ }
+
if (list->lock)
virSecurityManagerMetadataUnlock(list->manager, &state);
--
2.19.2