On Wed, May 16, 2012 at 2:31 PM, Eric Blake <ebl...@redhat.com> wrote: > On 05/16/2012 11:19 AM, Seth Jennings wrote: >> On Wed, May 16, 2012 at 12:06 PM, Eric Blake <ebl...@redhat.com> wrote: >>> On 05/16/2012 10:30 AM, Seth Jennings wrote: > Did you mean for this replay to go to the list?
Yes I did :-/ Back on the list. > You might also want to play with dynamic_ownership in > /etc/libvirt/qemu.conf, which changes whether libvirtd will chown in the > first place. That does the trick. Although, without dynamic_ownership, libvirt-qemu doesn't have write access to the LV I'm using as a virtio disk. So I guess it's a two edged sword. However, manually adding the libvirt-qemu user to the disk group fixed that. Might be a little coarse security-wise, but I don't feel like writing new udev rules for the device mapper today. <snip> > At least read access is required, for the uid that qemu will be running > as. If the file permissions _already_ grants read access, and libvirt > isn't recognizing that fact but doing the chown anyways, then that would > be something worth cleaning up. That is the case; it is chowning things even if it has the access required. Additionally, at least in Ubuntu 12.04, it does _not_ restore the original ownership. The initial chown when the VM starts is to libvirt-qemu:kvm, and once the VM shuts down, the ownership switches to root:root, regardless of the original ownership. Honestly, this could be used for privilege escalation of sorts. If I was a member of the libvirtd group, I could target a file owned by another user by making it the kernel for a VM and starting it. Of course, the VM wouldn't boot (unless the target file was actually a kernel image), but I would have successfully chowned that file to root:root using libvirtd, which runs a root, to do it. The user that originally owned the file would no longer be the owner. Thanks, Seth -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
