[all][privsep] Migrate from oslo.rootwrap to oslo.privsep
gmann at ghanshyammann.com
Mon Mar 23 01:16:10 UTC 2020
---- On Thu, 19 Mar 2020 10:45:23 -0500 Rodolfo Alonso <ralonsoh at redhat.com> wrote ----
> Hello all:
> With this mail I would like to propose the goal to move away from oslo.rootwrap and migrate to
> oslo.privsep. The last one offers a superior security model, faster and more secure. During the last
> cycles and since privsep was released, the Community has encouraged the usage of privsep and the
> deprecation of any existing code still using rootwrap.
> For any developer willing to collaborate, there are plenty of code examples, as I’ll provide later,
> implementing and using privsep for new methods and migrations.
> If this goal is approved, I'll open a Story (https://storyboard.openstack.org/) and any developer
> will be able to add a task for each patch or set of them related. This would be the tracker for this
> common effort.
Thanks Rodolfo for taking initiative on this effort, much appreciated.
Just to be clear, In this ML, we are checking this as a possible goal candidate for V cycle. I have mentioned this
ML link in etherpad: https://etherpad.openstack.org/p/YVR-v-series-goals
Once we get the heads up from ML and sort out the open questions, the next step will be to propose this as a goal in governance repo
governance/tree/master/goals/proposed. After this goal and its definition are accepted then we select this for cycle goal .
On/after it is selected as a cycle goal, then you as goal champion can start the storyboard for tracking.
> PROJECTS TO MIGRATE.
> Projects that are still using rootwrap:
> USAGE DOCUMENTATION ABOUT PRIVSEP.
> How to create a privsep context, assign privileges and use it as a decorator:
> HOW TO MIGRATE FROM ROOTWRAP TO PRIVSEP.
> From the same link provided previously, in the section “Converting from rootwrap to privsep”:
> oslo.privsep provides a class, PrivContext, that can be used to create a decorator function. The
> instance created is a context of execution and has defined a list of capabilities, matching the
> Linux capabilities. The privsep context decorator should contain the minimum needed capabilities to
> execute the decorated function.
> For example:
> default = priv_context.PrivContext(
> pypath=__name__ + '.default',
> The function “entrypoint” of this instance can be used as a decorator for another function:
> def delete_interface(ifname, namespace, **kwargs):
> _run_iproute_link("del", ifname, namespace, **kwargs)
> As commented in the given link, a straight 1:1 filter:function replacement generally results in
> functions that are still too broad for good security. It is better to replace each chmod rootwrap
> call with a narrow privsep function that will limit it to specific files.
> MIGRATION EXAMPLES.
> os-vif: https://review.opendev.org/#/c/287725/
> Thank you and regards.
More information about the openstack-discuss