[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
necessary.

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>
wrote:

>  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