Re: [libvirt] [PATCHv3 18/19] blockjob: refactor qemu disk chain permission grants
On 10/18/2012 12:50 PM, Laine Stump wrote:
On 10/17/2012 06:30 PM, Eric Blake wrote:
> 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.
>
ACK, with qualifying remarks from the review of the previous version of
the patch (PATCHv2 17/16)
I'm adding this to the commit message:
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).
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 617 bytes)