blockjob: refactor qemu disk chain permission grants
Previously, snapshot code did its own permission granting (lock manager, cgroup device controller, and security manager labeling) inline. But now that we are adding block-commit and block-copy which also have to change permissions, it's better to reuse common code for the task. While snapshot should fall back to no access if read-write access failed, block-commit will want to fall back to read-only access. The common code doesn't know whether failure to grant read-write access should revert to no access (snapshot, block-copy) or read-only access (block-commit). This code can also be used to revoke access to unused files after block-pull. It might be nice to clean things up in a future patch by adding new functions to the lock manager, cgroup manager, and security manager that takes a single file name and applies context of a disk to that file, rather than the current semantics of applying context to the entire chain already associated to a disk. That way, we could avoid the games this patch plays of temporarily swapping out the disk->src and related fields of the disk. But that would involve more code changes, so this patch really is the smallest hack for doing the necessary work; besides, this patch is more or less code motion (the hack was already employed by the snapshot creation code, we are just making it reusable). * src/qemu/qemu_driver.c (qemuDomainSnapshotCreateSingleDiskActive) (qemuDomainSnapshotUndoSingleDiskActive): Refactor labeling hacks... (qemuDomainPrepareDiskChainElement): ...into new function.
Showing
想要评论请 注册 或 登录