[openstack-dev] [neutron] Linux capabilities vs sudo/rootwrap?
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
> 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).
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev