Open Stack

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 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/b3cef342/attachment.html>