[openstack-dev] [nova] Initial oslo.privsep conversion?

Matt Riedemann mriedem at linux.vnet.ibm.com
Fri Jun 17 14:13:32 UTC 2016

On 6/9/2016 6:51 PM, Tony Breeds wrote:
> On Fri, Jun 10, 2016 at 08:24:34AM +1000, Michael Still wrote:
>> On Fri, Jun 10, 2016 at 7:18 AM, Tony Breeds <tony at bakeyournoodle.com>
>> wrote:
>>> On Wed, Jun 08, 2016 at 08:10:47PM -0500, Matt Riedemann wrote:
>>>> Agreed, but it's the worked example part that we don't have yet,
>>>> chicken/egg. So we can drop the hammer on all new things until someone
>>> does
>>>> it, which sucks, or hope that someone volunteers to work the first
>>> example.
>>> I'll work with gus to find a good example in nova and have patches up
>>> before
>>> the mid-cycle.  We can discuss next steps then.
>> Sorry to be a pain, but I'd really like that example to be non-trivial if
>> possible. One of the advantages of privsep is that we can push the logic
>> down closer to the privileged code, instead of just doing something "close"
>> and then parsing. I think reinforcing that idea in the sample code is
>> important.
> I think *any* change will show that.  I wanted to pick something achievable in
> the short timeframe.
> The example I'm thinking of is nova/virt/libvirt/utils.py:update_mtime()
>  * It will provide a lot of the boiler plate
>  * Show that we can now now replace an exec with pure python code.
>  * Show how you need to retrieve data from a trusted source on the priviledged
>    side
>  * Migrate testing
>  * Remove an entry from compute.filters
> Once that's implace chown() in the same file is probably a quick fix.
> Is it super helpful? does it have a measurable impact on performance, security?
> The answer is probably "no"
> I still think it has value.
> Handling qemu-img is probably best done by creating os-qemu (or similar) and
> designing from the ground up with provsep in mind.  Glance and Cinder would
> benefit from that also.  That howveer is waaay to big for this cycle.
> Yours Tony.
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

So I know we didn't want to block the virtuozzo resize patch for 
oslo.privsep conversion, but there is another vz package for their 
libvirt volume driver that's adding a new rootwrap filter:


We definitely don't want that one using rootwrap filters because it's 
going to couple os-brick / cinder / nova during upgrades, which is the 
reason we wanted to get oslo.privsep support into os-brick in the first 

So I think we're going to have to convert that one to use oslo.privsep. 
I might be mistaken though.

Given where this is, however, it's going to run into the issue we have 
with sorting out upgrades from mitaka (see Sean's thread) so that nova 
can register the root helper early with oslo.privsep when nova-compute 
starts up.



Matt Riedemann

More information about the OpenStack-dev mailing list