We have an ongoing effort in neutron to move to rootwrap-daemon. https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/rootwrap-daemon-mode,n,z
To speed up multiple system calls, and be able to spawn daemons inside namespaces. I have to read a bit what are the good & bad points of privsep. The advantage of rootwrap-daemon, is that we don’t need to change all our networking libraries across neutron, and we kill the sudo/rootwrap spawn for every call, yet keeping the rootwrap permission granularity. Miguel Ángel Ajo On Friday, 13 de February de 2015 at 10:54, Angus Lees wrote: > On Fri Feb 13 2015 at 5:45:36 PM Eric Windisch <e...@windisch.us > (mailto:e...@windisch.us)> wrote: > > ᐧ > > > > > > from neutron.agent.privileged.commands import ip_lib as priv_ip > > > def foo(): > > > # Need to create a new veth interface pair - that usually > > > requires root/NET_ADMIN > > > priv_ip.CreateLink('veth', 'veth0', peer='veth1') > > > > > > Because we now have elevated privileges directly (on the privileged > > > daemon side) without having to shell out through sudo, we can do all > > > sorts of nicer things like just using netlink directly to configure > > > networking. This avoids the overhead of executing subcommands, the > > > ugliness (and danger) of generating command lines and regex parsing > > > output, and make us less reliant on specific versions of command line > > > tools (since the kernel API should be very stable). > > > > One of the advantages of spawning a new process is being able to use flags > > to clone(2) and to set capabilities. This basically means to create > > containers, by some definition. Anything you have in a "privileged daemon" > > or privileged process ideally should reduce its privilege set for any > > operation it performs. That might mean it clones itself and executes > > Python, or it may execvp an executable, but either way, the new process > > would have less-than-full-privilege. > > > > For instance, writing a file might require root access, but does not need > > the ability to load kernel modules. Changing network interfaces does not > > need access to the filesystem, no more than changes to the filesystem needs > > access to the network. The capabilities and namespaces mechanisms resolve > > these security conundrums and simplify principle of least privilege. > > Agreed wholeheartedly, and I'd appreciate your thoughts on how I'm using > capabilities in this change. The privsep daemon limits itself to a > particular set of capabilities (and drops root). The assumption is that most > OpenStack services commonly need the same small set of capabilities to > perform their duties (neutron -> net_admin+sys_admin for example), so it > makes sense to reuse the same privileged process. > > If we have a single service that somehow needs to frequently use a broad > swathe of capabilities then we might want to break it up further somehow > between the different internal aspects (multiple privsep helpers?) - but is > there such a case? There's also no problems with mixing privsep for > frequent operations with the existing sudo/rootwrap approach for rare/awkward > cases. > > - Gus > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > (mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe) > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
