Aaron Conole <acon...@redhat.com> writes: > 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?
Ping? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
