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 <t...@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-requ...@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
__________________________________________________________________________
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
