[ovs-dev] to exec ovs-vsctl, or to emulate it?

[Neil McKee]

Thank you for your comments.  Very helpful.

Just one further question:  every time the daemon polls with ovs-vsctl to make sure nothing has changed,   I get more logging in /var/log/messages:

Sep  1 12:17:04 xenserver56 ovs-vsctl: 00001|vsctl|INFO|Called as /usr/bin/ovs-vsctl list sflow
Sep  1 12:17:04 xenserver56 ovs-vsctl: 00001|vsctl|INFO|Called as /usr/bin/ovs-vsctl list-br
Sep  1 12:17:04 xenserver56 ovs-vsctl: 00001|vsctl|INFO|Called as /usr/bin/ovs-vsctl get bridge xenbr0 sflow

This seems a little chatty.   Perhaps this logging could be reserved for invocations that attempt to modify the config (create, set, destroy,...)?

Neil


On Aug 29, 2010, at 2:17 PM, Ben Pfaff wrote:

> On Sun, Aug 29, 2010 at 1:58 PM, Neil McKee <neil.mckee at inmon.com> wrote:
>> I have a daemon written in C that invokes /usr/bin/ovs-vsctl to
>> configure sFlow on the local Open VSwitch,  and my question is about
>> how to do that securely.  I'm using pipe/fork/dup2/execve etc. to
>> bypass shell-expansion etc. so it's not a complete disaster from a
>> security point of view,   but  my daemon has to run all the time and
>> check/update the config periodically,  which means it has to retain
>> super-user privileges so it can call ovs-vsctl each time.
>> 
>> I suspect that I should really be connecting at the layer below:
>>  i.e. opening the unix domain socket to connect to the ovsdb server
>> and sending commands just like ovs-vsctl does.   That way I could
>> relinquish superuser privileges as soon as the socket was opened
>> (right?)
> 
> The one possible issue with that approach is that the socket can get
> closed.  Currently the dbserver sends an application-layer "ping"
> request if the socket is idle for 5 seconds, and if it doesn't get a
> response within another 5 seconds, it closes the socket.  (This
> behavior is really intended for scenarios other than yours, where
> connections can be unreliable.  We could work out a way to disable it
> for, say, Unix domain socket connections.)
> 
>> So my questions are:
> 
>> 1. Which API is more stable?  The ovs-vsctl command-line or the
>> underlying socket API?
> 
> I'd say that ovs-vsctl is more stable.  We've revved the protocol a
> couple of times without changing the ovs-vsctl interface.
> 
>> 2. If I really should be connecting to the socket API,  what is the
>> minimal #include that I would need?
> 
> If you want to use the socket API, you would want to #include
> "vswitch-idl.h", which is dynamically generated during the Open
> vSwitch build, plus lib/ovsdb-idl.h from the source tree.  I don't
> think we have a good "minimal" example of how to use this; the one
> that I would point to is actually written in Python using the very new
> Python bindings for OVSDB.
> 
>> 3. Should I just stick with what I have because the security
>> difference is marginal and the effort of emulating ovs-vsctl could
>> be non-trivial?
> 
> I think that is the direction that I would lean.
> 
> It might be possible to rig something up where ovs-vsctl uses a socket
> opened by the program that "exec"s it, passed e.g. by
> "--db=unix:/dev/fd/<n>".  I haven't tried that.  It might just work.
> 
> Another possibility is a small setuid root program that makes a specific
> call to ovs-vsctl in the form that you want.
> 
>> 4. If I continue to use ovs-vsctl,  what is the best way of ensuring
>> that /usr/bin/ovs-vsctl is genuine,  and that OpenVSwitch is
>> actually installed and running?   I was thinking I would just have
>> to check the permissions on /usr/bin/ovs-vsctl (and /usr/bin) to
>> make sure that it is owned by root and only root could change it,
>> but maybe there is a better way to know that I can trust it?
> 
> Most of the time on Unix systems one can make the assumption that
> anything in /usr/bin is sanctioned by root, because only root has
> write permission to /usr/bin.  I'm not sure what I can assume instead
> if I can't assume that, so I don't know what to suggest.