Christian Ehrhardt <christian.ehrha...@canonical.com> writes: > On Tue, May 24, 2016 at 4:10 PM, Aaron Conole <acon...@redhat.com> wrote: > >> Daniele Di Proietto <diproiet...@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. >> > > Hi, > IIRC we kind of agree that long term a proper MAC will be much better but > most involved people needed something to get it working like "now". > Since they are complementary (other than the fix removing a bit of the > urgency for more MAC) it was kind of the least bad option. > > You have to be aware that I brought up the discussion on d...@dpdk.org - see > [1] and [2]: > But this will take time and eventually still be the applications task to > "do something" - no matter if via API or via the chmod's right now. > So Aaron is trying to get something that works now until the long term > things are in place, which I appreciate. > > FYI - I was even more in a hurry as it was clear that OVS-2.5 won't get > this in time I run with [3] for now. > I never intended to suggest that, but with the discussion in place, one > could ask if you (Aaron) want to pick up that instead. > That would keep OVS free for now until DPDK made up the API (see [2]) for > socket ownership control and this then could be implemented in OVS? > > (I hope) In some months/years we will all be happy to drop this bunch of > interim solutions, never the less we need it for now. > > [1]: http://dpdk.org/dev/patchwork/patch/12222/ > [2]: http://dpdk.org/ml/archives/dev/2015-December/030326.html > [3]: > https://git.launchpad.net/~ubuntu-server/dpdk/commit/?h=ubuntu-xenial-to-dpdk2.2&id=f3c7aa1b2ddea8e092ad4a89e41a0e19d01ed4e7 > > [...] > > >> I think originally we quickly discussed 4 possible solutions (and >> hopefully I captured them correctly): >> >> 1. OVS downgrades to the ovs user, and kvm runs under the ovs >> group. I don't actually like this solution because kvm could then >> pollute the ovs database. >> >> 2. OVS runs as some user and sets the user/group ownership of the socket >> via chown/chmod where permissions come from the database (the >> original context had ovs running as root - but as I described above >> it doesn't need to be root provided ovs+DPDK can start without root). >> >> 3. OVS runs as some user, kvm starts as root, opens the socket and >> downgrades. IIRC, this doesn't actually work, or it may have >> implications on other projects. I don't remember exactly what was >> not as great about this solution, TBH. >> >> 4. OVS and KVM run as whatever users; MAC is used to enforce the >> layering between them. >> >> I think solution 2 and solution 4 don't actually interfere with each >> other, and can be used to a complementary effect (if implemented >> properly) so that the MAC layer enforces access, but even without MAC, >> the DAC layer can provide appropriate whitelisting behavior. >> > > I also remember several complex changes needed for the #1 and #3 that > always would end up with huge effort and a high risk not being accepted. > Probably that is what you refer to with "implications on other projects". > > Also keep in mind the position of dpdk out of the last few discussions > which I'd like to summarize as "dpdk got this path from an app, so this app > OWNS that path".
I'd like to continue on, but I am not sure what the concerns are right now. Is it possible to enumerate them point by point so that I can understand them? I think there are two outstanding concerns right now: 1. the proposed approach is not good enough (vis-a-vis DAC vs. MAC) 2. the proposed approach would be better implemented in the utility that wants access to the sockets (vis-a-vis the libvirt discussion) Am I understanding the concerns correctly? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
