Open Stack

17.06.2016 17:13, Matt Riedemann пишет:

> 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:
>
> https://review.openstack.org/#/c/190843/
>
> 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 place.
>
> 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.
>

Looks like we don't need a new rootwrap filter for the mentioned patch. 
It isn't necessary with upstream os-brick, so we can easily remove it 
from the change.

Maxim