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

Ben Pfaff blp at nicira.com
Sun Aug 29 21:17:13 UTC 2010

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.

More information about the dev mailing list