Ansis Atteka <ansisatt...@gmail.com> writes: > On 20 May 2016 at 13:32, Aaron Conole <acon...@redhat.com> wrote: > >> Currently, when using Open vSwitch with DPDK and qemu guests, the >> recommended >> method for joining the guests is via the dpdkvhostuser interface. This >> interface uses Unix Domain sockets to communicate. When these sockets are >> created, they inherit the permissions and ownership from the vswitchd >> process. >> This can lead to an undesirable state where the QEMU process cannot use the >> socket file until manual intervention is performed (via `chown` and/or >> `chmod` >> calls). >> > > Hi Aaron, > > Could you explain: > 1. who would be setting the owner via this newly introduced OVSDB interface?
I always viewed this as a feature of convenience in the following case: 1. Start Open vSwitch 2. Start DPDK 3. Run qemu (as a non-root user) 3a. Observe failure (permission denied) 4. Okay, darn - ch*() files 5. Re-run qemu 5a. Observe success As a user, I am not very smart. I don't see a way to set things like umasks, directory group bits, or anything else. And I don't see any such knobs in Open vSwitch today. If your question is for a specific user I have in mind, I don't have one. I'm thinking about the general case. What is the most _useful_ thing to provide. I think a combination of MAC and DAC approaches make sense, but as I said in the previous paragraph - "I am not very smart." :-) > 2. who would be starting the QEMU process for use-cases you are trying to > solve here? > > I am asking this because in another thread [ > http://openvswitch.org/pipermail/dev/2016-June/071935.html] I had > discussion with Libvirt folks and they explained to me that under their > current security model they think it should be Libvirt doing the actual > chown() calls and that they would prefer not use Open vSwitch as a proxy to > do it for them. This is at least what they apparently have been doing all > this time to lock down privileges for QEMU processes. That's great. That means libvirt may actually do something to make this easier. However, what about the _next_ hypervisor that comes along? Or the next vhost-user based back-end? Those still require some kind of solution, and having the ability to at least fall back on DAC is quite handy. It feels more complete. > Some food for thoughts: > 1. What, if in future Libvirt will chown() the DPDK sockets directly and > override the value set in OVSDB (assuming QEMU is started by libvirt, but > ovs-vsctl is invoked by some other process)? That's fine. It's no different than today (just imagine that libvirt is fixed to calling chown and chmod, without changing from the current user/group and umask values). > 2. What about Mandatory Access Control security context (the one you see in > `ls -Z <file>` output on RHEL-type distributions)? Do you plan to set it as > well in the future from ovs-vswitchd? MAC is another security layer that > Libvirt uses to confine QEMU. I think it should be used as well. I don't think these are competing technologies, or a case where we need to provide one vs. another. I view them as complementary, and we have the opportunity to provide both. That way, at least on systems where users decide that `setenforce Permissive` is a fine thing to do, there's something that does provide some semblance of control. The way it stands now is confusing. > 3. Also this patch kinda conflicts with --user flag because then ovs user > would have to be put under "qemu" group to be able to chown sockets to > "qemu" user. This reexposes OVS to untrusted resources owned by qemu user. > Anyway this flag does not work with DPDK anyway and I think we may want to > deprecate it. For now, I am going to leave this alone. DPDK requires root access at the moment, so it's only vaguely relevant. > Also what you have may be completely fine: > 1. as a short term solution for Libvirt if it currently does not chown() > DPDK sockets; OR I agree, this does provide a solution in that case as well. I'm not currently working on libvirt for this. > 2. if you are targeting this feature for hypervisors that are not using > Libvirt and have completely different security model. I think it needs to be considered. OvS isn't part of libvirt, so the features provided should really be considerate of other deployments, as well. Hopefully I don't sound too naive, and I've made a case why this feature is good to have. -Aaron _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
