[ovs-dev] to exec ovs-vsctl, or to emulate it?
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
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