[ovs-dev] [PATCH v2 2/2] netdev-dpdk: Support user-defined socket attribs

Aaron Conole aconole at redhat.com
Fri Jun 3 18:43:41 UTC 2016


Christian Ehrhardt <christian.ehrhardt at canonical.com> writes:

> On Tue, May 24, 2016 at 4:10 PM, Aaron Conole <aconole at redhat.com> wrote:
>
>> Daniele Di Proietto <diproiettod at 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 dev at 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?



More information about the dev mailing list