Context elevated on reschedule

[Joshua Harlow]

When a volume is initially created the context is immediately elevated (in the volume.manager code) to admin level and if the volume is not created successfully then the rescheduling logic will send back out that elevated context to the scheduler. This seems like a privilege escalation which was not intended (since before the create_volume() call occurred the context was not elevated and if it fails then it becomes elevated). I am not sure of the side-effects this could have, but it seems likely unintended to elevate an unprivileged context, try creation, fail and then send out the elevated context for further scheduling.

[Thierry Carrez (ttx)]

I don't think this classifies as an exploitable vulnerability, unless I'm missing something. Sounds more like a bug that needs to be fixed... in which case I'd rather handle it in the open rather than in embargo mode.

Raise your hand if you object to the opening of this bug

[John Griffith (john-griffith)]

+1, don't think this is a security issue.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/35496

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/35496
Committed: http://github.com/openstack/cinder/commit/ca0e7295f44235c7d64954a225a172718a074dd8
Submitter: Jenkins
Branch: master

commit ca0e7295f44235c7d64954a225a172718a074dd8
Author: XueChendi <email address hidden>
Date: Wed Jul 3 22:20:32 2013 +0800

    Prevent wrongly privilege escalation of a context

    Current codes in create_volume() may exists a scenario that
    a context which is not elevated but after it fails in volume
    creation, it becomes elevated. This patch saves original
    context, so that if it fails in volume creation simply use the
    original context for further scheduling.

    Fix bug:1187076

    Change-Id: I2822b1612ec741209b278fc65f18d0f8f3243e0a