[openstack-dev] [neutron] Linux capabilities vs sudo/rootwrap?

Angus Lees gus at inodes.org
Wed Dec 10 04:59:50 UTC 2014

Afaik ovs-vsctl just talks to ovsdb-server via some regular IPC mechanism -
usually a unix socket, see --db.  So yes, provided the file permissions on
the unix socket work out, then no root powers (or any kernel capability) is

Having said that, there will be plenty of examples where sudo/rootwrap is
still required.  I'm not suggesting we can (or should!) get rid of it
entirely - just for basic network configuration.

On Wed Dec 10 2014 at 12:42:46 PM George Shuklin <george.shuklin at gmail.com>

>  Is ovs-vsctl gonna be happy with CAP_NET_ADMIN?
> On 12/10/2014 02:43 AM, Angus Lees wrote:
> [I tried to find any previous discussion of this and failed - I'd
> appreciate a pointer to any email threads / specs where this has already
> been discussed.]
>  Currently neutron is given the ability to do just about anything to
> networking via rootwrap, sudo, and the IpFilter check (allow anything
> except 'netns exec').  This is completely in line with the role a typical
> neutron agent is expected to play on the local system.
>  There are also recurring discussions/issues around the overhead of
> rootwrap, costs of sudo calls, etc - and projects such as rootwrap daemon
> underway to improve this.
>  How crazy would it be to just give neutron CAP_NET_ADMIN (where
> required), and allow it to make network changes via ip (netlink) calls
> directly?
> We will still need rootwrap/sudo for other cases, but this should remove a
> lot of the separate process overhead for common operations, make us
> independent of iproute cli versions, and allow us to use a direct
> programmatic API (rtnetlink and other syscalls) rather than generating
> command lines and regex parsing output everywhere.
>  For what it's worth, CAP_NET_ADMIN is not sufficient to allow 'netns
> exec' (requires CAP_SYS_ADMIN), so it preserves the IpFilter semantics. On
> the downside, many of the frequent rootwrap calls _do_ involve
> creating/modifying network namespaces so we wouldn't see advantages for
> these cases.  I need to experiment further before having a proposal for
> that part (just granting CAP_SYS_ADMIN too is too broad; user namespaces
> help a lot, but they're very new and scary so not available everywhere).
>  Thoughts?
> _______________________________________________
> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>  _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141210/746a123c/attachment.html>

More information about the OpenStack-dev mailing list