Re: [libvirt] [ovs-dev] [PATCH v2 2/2] netdev-dpdk: Support user-defined socket attribs
On Mon, May 30, 2016 at 01:27:46PM -0700, Ansis Atteka wrote:
On Mon, May 30, 2016 at 12:29 AM, Christian Ehrhardt
<christian.ehrhardt(a)canonical.com> wrote:
> On Tue, May 24, 2016 at 4:10 PM, Aaron Conole <aconole(a)redhat.com> wrote:
>
>> Daniele Di Proietto <diproiettod(a)vmware.com> writes:
>>
>> > Hi Aaron,
>> >
>> > I'm still a little bit nervous about calling chown on a (partially)
>> > user controlled file name.
>>
>> I agree, that always seems scary.
>>
>> > Before moving forward I wanted to discuss a couple of other options:
>> >
>> > * Ansis (in CC) suggested using -runas parameter in qemu. This way
>> > qemu can open the socket as root and drop privileges before starting
>> > guest execution.
>>
>> I'm not sure how to do this with libvirt, or via the OpenStack Neutron
>> plugin. I also don't know if it would be an acceptable workaround for
>> users. Additionally, I recall there being something of a "don't even
>> know if this works" around it. Maybe Christian or Ansis (both in CC)
>> can expound on it.
>>
Cross-posting to libvirt mailing list to hear opinion from libvirt developers.
In short - the problem is that libvirtd process starts qemu process
under non-root user. Since qemu starts under non-root process, then
qemu can't connect to DPDK unix domain sockets created by ovs-vswitcd
process that runs under "root". There are two solutions to this
problem:
1. let ovs-vswitchd process to chown its socket from "root" to
"libvirt" group and/or user (this is what Aarons patch proposes)
2. make libvirtd process to start qemu process under "root" but then
let qemu to downgrade via "-run-as" flag after qemu has opened the
Unix Domain socket.
Regarding solution #2. I think the necessary changes roughly would be to:
1. invoke virCommandAddArgPair(cmd, "-runas", "libvirt") before
starting qemu process; AND
2. revert virCommandSetUID() that automatically downgrades user from
"root" to "libvirt" even before qemu starts.
I would like to hear feasibility of such solution from libvirt
developers? Or maybe there is even a better solution that I am
missing?
That's not going to happen. Libvirt consider QEMU to be untrustworthy
in general and so apply multiple techniques to confine QEMU before it is
exec'd. This include dropping to non-0 uid/gid, applying apparmour/selinux
policies, putting it in restricted cgroups, and potentially more in the
future such as putting it in custom namespaces. We've no desire to use
qemu's -runas, as that means we're trusting QEMU to actually drop privileges
as it claims to.
Libvirt's model is that libvirt will setup policies to allow QEMU access
to the specific resources that it needs. so eg libvirt will chown the
disk images associated with the VM to give it access.
I'm missing history of this thread, but IIUC, the issue here is access
to the UNIX domain socket associated with the vhost-user network backend
for QEMU. If so, then I think it is a case where libvirt should be setting
ownershup on that socket before starting QEMU, in order to grant access.
This of course assumes there is a separate UNIX domain socket per VM
that is launched.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|