Re: [openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"
2016-09-22 15:58 GMT+02:00 Matt Riedemann : > 1. We don't bump minimums just because a new thing comes out in a given > release, we only bump minimums when something that uses that dependency > needs a higher minimum version. > > 2. Looking at this: > > https://github.com/openstack/releases/blob/master/deliverables/liberty/oslo.concurrency.yaml > > I read the first release of oslo.concurrency in liberty was 1.9.0, not > 2.6.0. I meant first after stable/liberty was branched, without bumping to that before release we end up with a situation like this, where we don't have a release vehicle for stable fixes in the libraries. Cheers, Alan __ 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
Re: [openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"
On Tue, Sep 20, 2016 at 12:48:49PM +0200, Kashyap Chamarthy wrote: > The said patch in question fixes a CVE[x] in stable/liberty. > > We currently have two options, both of them have caused an impasse with > the Nova upstream / stable maintainers. We've had two-ish months to > mull over this. I'd prefer to get this out of a limbo, & bring this to > a logical conclusion. > > The two options at hand: > > (1) Nova backport from master (that also adds a check for the presence > of 'ProcessLimits' attribute which is only present in > oslo.concurrency>=2.6.1; and a conditional check for 'prlimit' > parameter in qemu_img_info() method.) > > https://review.openstack.org/#/c/327624/ -- "virt: set address space > & CPU time limits when running qemu-img" Conclusion: After discussion and analysis on this thread, especially Tony's response here[*], we went the route of option (1) above, and it is now merged in stable/liberty http://git.openstack.org/cgit/openstack/nova/commit/?h=stable/liberty&id=6bc37dc Jeremy said (on #openstack-stable) he's going to follow up on the bug for the security advisory. Thanks everyone! [*] http://lists.openstack.org/pipermail/openstack-dev/2016-September/104303.html > (2) Or bump global-requirements for 'oslo.concurrency' > > https://review.openstack.org/#/c/337277/5 -- Bump > 'global-requirements' for 'oslo.concurrency' to 2.6.1 > > Both patches have had long (and useful) discussion about their merits / > demerits in the review comments in context of stable backports. If you > have sometime, I'd recommend going through the comments in both the > reviews provides all the context, current disagreements. > > > > [x] https://bugs.launchpad.net/nova/+bug/1449062 -- > qemu-img calls need to be restricted by ulimit (CVE-2015-5162) -- /kashyap __ 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
Re: [openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"
On 9/22/2016 8:05 AM, Alan Pevec wrote: We have: * global-requirements.txt: origin/stable/liberty : oslo.concurrency>=2.3.0 # Apache-2.0 But wasn't that wrong from the start? First Liberty release of oslo.concurrency was 2.6.0 why was that not bumped in g-r ? Cheers, Alan __ 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 Two things: 1. We don't bump minimums just because a new thing comes out in a given release, we only bump minimums when something that uses that dependency needs a higher minimum version. 2. Looking at this: https://github.com/openstack/releases/blob/master/deliverables/liberty/oslo.concurrency.yaml I read the first release of oslo.concurrency in liberty was 1.9.0, not 2.6.0. -- Thanks, Matt Riedemann __ 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
Re: [openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"
> We have: > * global-requirements.txt: > origin/stable/liberty : oslo.concurrency>=2.3.0 # Apache-2.0 But wasn't that wrong from the start? First Liberty release of oslo.concurrency was 2.6.0 why was that not bumped in g-r ? Cheers, Alan __ 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
Re: [openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"
On Thu, Sep 22, 2016 at 04:25:00PM +1000, Tony Breeds wrote: > On Wed, Sep 21, 2016 at 02:05:51PM -0400, Sean Dague wrote: > > > Well, the risk profile of what has to be changed for stable/liberty > > (given that all the actual code is buried in libraries which have tons > > of other changes). Special cherry-picked library versions would be > > needed to fix this without openning up a ton of risk for breaking > > stable/liberty badly. > > > > That is the bit of work that no one seems to really have picked up. > > So to clearly describe the work you touch on here: > > We have: > * global-requirements.txt: > origin/stable/liberty : oslo.concurrency>=2.3.0 # Apache-2.0 > * upper-constraints.txt > origin/stable/liberty : oslo.concurrency===2.6.1 > * compatible oslo.concurrency releases: > 2.3.0, 2.4.0, 2.5.0, 2.6.0 and 2.6.1(patched) > > So to be sure that all liberty consumers have a reasonably simple update we'd > need to create: > 2.3.1, 2.4.1 and 2.5.1 > releases of oslo.concurrency > > To achieve this we'd need to create a 3 short lived feature branches in > oslo.concurrency and (I'm guessing) some CI changes so we can merge/release > these versions. > > We'd also need to update global-requirements.txt to: > oslo.concurrency>=2.3.1,!=2.4.0,!=2.5.0,!=2.6.0 > > This update would be propagated to all projects: > > Package : oslo-concurrency [oslo-concurrency>=2.3.0] (used by 30 > projects) > Re-Release : 5 projects > Included in : 17 projects > Also affects : 8 projects > > (The expanded list is at http://paste.openstack.org/show/582499/) > > I haven't looked into the state of the libraries that need a re-release, but > my > guess is that they'll have knock on effects if we're going to do this > properly. > > There's a reason we call this kind of thing a tangled web of onions. > > I suppose the most flexible solution would be to: > > 1. Release the .1 versions > 2. Leave global-requirements.txt > 2. Add the patch to nova to with with/without the fix > 3. Write appropriate words in the OSSN/OSSA > > That gives deployers plenty of packages they can work with and public > backports > of the fixes. Yes g-r would be sub-optimal but the only thing that needs the > fix will function with any of the versions listed. Thanks for the succint analysis, Tony, that gives a clear view of state of affairs if we had to go with three short-lived .1 releases. Probably this thread needs to be referred to in the commit message. > Time passes > > So I checked and the cherry-picks to 2.[345].0 are trivial so I think > I just talked myself around to taking the nova fix now we can decide > if we do all the .1 releases later So, given your above comment, we seem to be going with the "option (1)" as mentioned in the original post[x] -- i.e. merge the Nova backport. Thanks for the review (and the test with 2.6.0) [x] http://lists.openstack.org/pipermail/openstack-dev/2016-September/104091.html -- /kashyap __ 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
Re: [openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"
On Wed, Sep 21, 2016 at 02:05:51PM -0400, Sean Dague wrote: > Well, the risk profile of what has to be changed for stable/liberty > (given that all the actual code is buried in libraries which have tons > of other changes). Special cherry-picked library versions would be > needed to fix this without openning up a ton of risk for breaking > stable/liberty badly. > > That is the bit of work that no one seems to really have picked up. So to clearly describe the work you touch on here: We have: * global-requirements.txt: origin/stable/liberty : oslo.concurrency>=2.3.0 # Apache-2.0 * upper-constraints.txt origin/stable/liberty : oslo.concurrency===2.6.1 * compatible oslo.concurrency releases: 2.3.0, 2.4.0, 2.5.0, 2.6.0 and 2.6.1(patched) So to be sure that all liberty consumers have a reasonably simple update we'd need to create: 2.3.1, 2.4.1 and 2.5.1 releases of oslo.concurrency To achieve this we'd need to create a 3 short lived feature branches in oslo.concurrency and (I'm guessing) some CI changes so we can merge/release these versions. We'd also need to update global-requirements.txt to: oslo.concurrency>=2.3.1,!=2.4.0,!=2.5.0,!=2.6.0 This update would be propagated to all projects: Package : oslo-concurrency [oslo-concurrency>=2.3.0] (used by 30 projects) Re-Release : 5 projects Included in : 17 projects Also affects : 8 projects (The expanded list is at http://paste.openstack.org/show/582499/) I haven't looked into the state of the libraries that need a re-release, but my guess is that they'll have knock on effects if we're going to do this properly. There's a reason we call this kind of thing a tangled web of onions. I suppose the most flexible solution would be to: 1. Release the .1 versions 2. Leave global-requirements.txt 2. Add the patch to nova to with with/without the fix 3. Write appropriate words in the OSSN/OSSA That gives deployers plenty of packages they can work with and public backports of the fixes. Yes g-r would be sub-optimal but the only thing that needs the fix will function with any of the versions listed. Time passes So I checked and the cherry-picks to 2.[345].0 are trivial so I think I just talked myself around to taking the nova fix now we can decide if we do all the .1 releases later Yours Tony. signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"
On 2016-09-21 14:05:51 -0400 (-0400), Sean Dague wrote: [...] > Well, the risk profile of what has to be changed for stable/liberty > (given that all the actual code is buried in libraries which have tons > of other changes). Special cherry-picked library versions would be > needed to fix this without openning up a ton of risk for breaking > stable/liberty badly. > > That is the bit of work that no one seems to really have picked up. Makes sense. It's also possible in that case that it's not a sign of stable/liberty being unmaintainable, but rather implies that the vulnerability as fixed in stable/mitaka falls below the effective severity threshold to warrant a security advisory. Put another way, I'd like to find some reasonable means to explain the lack of a fix in a "supported" stable branch. If the VMT and stable branch maintainers need accept the possibility that something can be treated as a vulnerability by the OpenStack community but only fixed in some supported branches, that introduces a lot of additional uncertainty for downstream consumers of our advisory process and the associated patches tracked by it. -- Jeremy Stanley signature.asc Description: Digital signature __ 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
Re: [openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"
On 09/21/2016 02:03 PM, Jeremy Stanley wrote: > On 2016-09-21 15:41:11 +1000 (+1000), Tony Breeds wrote: >> On Tue, Sep 20, 2016 at 11:57:26AM +0100, Daniel P. Berrange wrote: > [...] >>> (3) Do nothing, leave the bug unfixed in stable/liberty >>> >>> While this is a security bug, it is one that has existed in every single >>> openstack release ever, and it is not a particularly severe bug. Even if >>> we fixed in liberty, it would still remain unfixed in every release before >>> liberty. We're in the verge of releasing Newton at which point liberty >>> becomes less relevant. So I question whether it is worth spending more >>> effort on dealing with this in liberty upstream. Downstream vendors >>> still have the option to do either (1) or (2) in their own private >>> branches if they so desire, regardless of whether we fix it upstream. >> >> I think 3 is the least worst option. > [...] > > At least from my perspective with my VMT hat on, declaring that we > have a security vulnerability severe enough to fix in stable/mitaka > but unfixable in stable/liberty calls into question whether the > latter is actually maintainable by our general definition as a > project or is ready for EOL. Well, the risk profile of what has to be changed for stable/liberty (given that all the actual code is buried in libraries which have tons of other changes). Special cherry-picked library versions would be needed to fix this without openning up a ton of risk for breaking stable/liberty badly. That is the bit of work that no one seems to really have picked up. -Sean -- Sean Dague http://dague.net __ 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
Re: [openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"
On 2016-09-21 15:41:11 +1000 (+1000), Tony Breeds wrote: > On Tue, Sep 20, 2016 at 11:57:26AM +0100, Daniel P. Berrange wrote: [...] > > (3) Do nothing, leave the bug unfixed in stable/liberty > > > > While this is a security bug, it is one that has existed in every single > > openstack release ever, and it is not a particularly severe bug. Even if > > we fixed in liberty, it would still remain unfixed in every release before > > liberty. We're in the verge of releasing Newton at which point liberty > > becomes less relevant. So I question whether it is worth spending more > > effort on dealing with this in liberty upstream. Downstream vendors > > still have the option to do either (1) or (2) in their own private > > branches if they so desire, regardless of whether we fix it upstream. > > I think 3 is the least worst option. [...] At least from my perspective with my VMT hat on, declaring that we have a security vulnerability severe enough to fix in stable/mitaka but unfixable in stable/liberty calls into question whether the latter is actually maintainable by our general definition as a project or is ready for EOL. -- Jeremy Stanley signature.asc Description: Digital signature __ 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
Re: [openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"
On Tue, Sep 20, 2016 at 11:57:26AM +0100, Daniel P. Berrange wrote: > On Tue, Sep 20, 2016 at 12:48:49PM +0200, Kashyap Chamarthy wrote: > > The said patch in question fixes a CVE[x] in stable/liberty. > > > > We currently have two options, both of them have caused an impasse with > > the Nova upstream / stable maintainers. We've had two-ish months to > > mull over this. I'd prefer to get this out of a limbo, & bring this to > > a logical conclusion. > > > > The two options at hand: > > > > (1) Nova backport from master (that also adds a check for the presence > > of 'ProcessLimits' attribute which is only present in > > oslo.concurrency>=2.6.1; and a conditional check for 'prlimit' > > parameter in qemu_img_info() method.) > > > > https://review.openstack.org/#/c/327624/ -- "virt: set address space > > & CPU time limits when running qemu-img" > > > > (2) Or bump global-requirements for 'oslo.concurrency' > > > > https://review.openstack.org/#/c/337277/5 -- Bump > > 'global-requirements' for 'oslo.concurrency' to 2.6.1 > > Actually we have 3 options > > (3) Do nothing, leave the bug unfixed in stable/liberty > > While this is a security bug, it is one that has existed in every single > openstack release ever, and it is not a particularly severe bug. Even if > we fixed in liberty, it would still remain unfixed in every release before > liberty. We're in the verge of releasing Newton at which point liberty > becomes less relevant. So I question whether it is worth spending more > effort on dealing with this in liberty upstream. Downstream vendors > still have the option to do either (1) or (2) in their own private > branches if they so desire, regardless of whether we fix it upstream. I think 3 is the least worst option. If we're going to do something else then it'd need to be (1). I feel like we need to rule out (2). I'll hack something up in the requirements repo to show that the try/except does what is needed which oslo.concurrency is < 2.6.1 Yours Tony. signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"
On 9/20/2016 4:17 PM, Matt Riedemann wrote: On 9/20/2016 7:38 AM, Alan Pevec wrote: 2016-09-20 13:27 GMT+02:00 Kashyap Chamarthy : (3) Do nothing, leave the bug unfixed in stable/liberty That was the unspoken third option, thanks for spelling it out. :-) Yes, let's abandon both reviews. Cheers, Alan __ 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 I'd rather not bump the minimum on oslo.concurrency given the transitive dependencies that would be pulled in which required higher minimums. So if I had to choose I'd go with the nova backport with the workaround: https://review.openstack.org/#/c/327624/ Which logs an error if you don't have a new enough oslo.concurrency. But I'm also fine with just considering this a latent bug as danpb pointed out and let downstream packagers/vendors handle it as they see fit. BTW, with my downstream hat on, if I were backporting this and packaging it, I'd personally cherry pick the oslo.concurrency fix that is required to whatever version of oslo.concurrency we shipped in each release and bump the patch version on our rpm. Then patch the nova fix in and make the nova rpm dependent on that patched oslo.concurrency rpm version. But that's just me. We were constrained by legal approval on which versions of something we could ship, and after a release those were basically frozen, so we couldn't just pick up new minimums and would workaround that by patching in the fixes we actually needed and tied the dependent versions between the rpms. -- Thanks, Matt Riedemann __ 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
Re: [openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"
On 9/20/2016 7:38 AM, Alan Pevec wrote: 2016-09-20 13:27 GMT+02:00 Kashyap Chamarthy : (3) Do nothing, leave the bug unfixed in stable/liberty That was the unspoken third option, thanks for spelling it out. :-) Yes, let's abandon both reviews. Cheers, Alan __ 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 I'd rather not bump the minimum on oslo.concurrency given the transitive dependencies that would be pulled in which required higher minimums. So if I had to choose I'd go with the nova backport with the workaround: https://review.openstack.org/#/c/327624/ Which logs an error if you don't have a new enough oslo.concurrency. But I'm also fine with just considering this a latent bug as danpb pointed out and let downstream packagers/vendors handle it as they see fit. -- Thanks, Matt Riedemann __ 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
Re: [openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"
2016-09-20 13:27 GMT+02:00 Kashyap Chamarthy : >> (3) Do nothing, leave the bug unfixed in stable/liberty > > That was the unspoken third option, thanks for spelling it out. :-) Yes, let's abandon both reviews. Cheers, Alan __ 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
Re: [openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"
On Tue, Sep 20, 2016 at 11:57:26AM +0100, Daniel P. Berrange wrote: > On Tue, Sep 20, 2016 at 12:48:49PM +0200, Kashyap Chamarthy wrote: [...] > > The two options at hand: > > > > (1) Nova backport from master (that also adds a check for the presence > > of 'ProcessLimits' attribute which is only present in > > oslo.concurrency>=2.6.1; and a conditional check for 'prlimit' > > parameter in qemu_img_info() method.) > > > > https://review.openstack.org/#/c/327624/ -- "virt: set address space > > & CPU time limits when running qemu-img" > > > > (2) Or bump global-requirements for 'oslo.concurrency' > > > > https://review.openstack.org/#/c/337277/5 -- Bump > > 'global-requirements' for 'oslo.concurrency' to 2.6.1 > > Actually we have 3 options > > (3) Do nothing, leave the bug unfixed in stable/liberty That was the unspoken third option, thanks for spelling it out. :-) > While this is a security bug, it is one that has existed in every > single openstack release ever, and it is not a particularly severe > bug. Even if we fixed in liberty, it would still remain unfixed in > every release before liberty. We're in the verge of releasing Newton > at which point liberty becomes less relevant. So I question whether it > is worth spending more effort on dealing with this in liberty > upstream. Downstream vendors still have the option to do either (1) > or (2) in their own private branches if they so desire, regardless of > whether we fix it upstream. Sure, I agree with what you said. This patch started off 2-ish months ago, at that time it wasn't the "verge of releasing Newton". That said, if upstream feels it's not really necessary to get this into Liberty, then I'm fine abandoning it, and close this. That's at least brings this to a conclusion. -- /kashyap __ 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
Re: [openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"
On Tue, Sep 20, 2016 at 12:48:49PM +0200, Kashyap Chamarthy wrote: > The said patch in question fixes a CVE[x] in stable/liberty. > > We currently have two options, both of them have caused an impasse with > the Nova upstream / stable maintainers. We've had two-ish months to > mull over this. I'd prefer to get this out of a limbo, & bring this to > a logical conclusion. > > The two options at hand: > > (1) Nova backport from master (that also adds a check for the presence > of 'ProcessLimits' attribute which is only present in > oslo.concurrency>=2.6.1; and a conditional check for 'prlimit' > parameter in qemu_img_info() method.) > > https://review.openstack.org/#/c/327624/ -- "virt: set address space > & CPU time limits when running qemu-img" > > (2) Or bump global-requirements for 'oslo.concurrency' > > https://review.openstack.org/#/c/337277/5 -- Bump > 'global-requirements' for 'oslo.concurrency' to 2.6.1 Actually we have 3 options (3) Do nothing, leave the bug unfixed in stable/liberty While this is a security bug, it is one that has existed in every single openstack release ever, and it is not a particularly severe bug. Even if we fixed in liberty, it would still remain unfixed in every release before liberty. We're in the verge of releasing Newton at which point liberty becomes less relevant. So I question whether it is worth spending more effort on dealing with this in liberty upstream. Downstream vendors still have the option to do either (1) or (2) in their own private branches if they so desire, regardless of whether we fix it upstream. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ 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
[openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"
The said patch in question fixes a CVE[x] in stable/liberty. We currently have two options, both of them have caused an impasse with the Nova upstream / stable maintainers. We've had two-ish months to mull over this. I'd prefer to get this out of a limbo, & bring this to a logical conclusion. The two options at hand: (1) Nova backport from master (that also adds a check for the presence of 'ProcessLimits' attribute which is only present in oslo.concurrency>=2.6.1; and a conditional check for 'prlimit' parameter in qemu_img_info() method.) https://review.openstack.org/#/c/327624/ -- "virt: set address space & CPU time limits when running qemu-img" (2) Or bump global-requirements for 'oslo.concurrency' https://review.openstack.org/#/c/337277/5 -- Bump 'global-requirements' for 'oslo.concurrency' to 2.6.1 Both patches have had long (and useful) discussion about their merits / demerits in the review comments in context of stable backports. If you have sometime, I'd recommend going through the comments in both the reviews provides all the context, current disagreements. [x] https://bugs.launchpad.net/nova/+bug/1449062 -- qemu-img calls need to be restricted by ulimit (CVE-2015-5162) -- /kashyap __ 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
