From commits-return-71573-archive-asf-public=cust-asf.ponee.io@cloudstack.apache.org Thu Feb 1 14:05:09 2018 Return-Path: X-Original-To: archive-asf-public@eu.ponee.io Delivered-To: archive-asf-public@eu.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by mx-eu-01.ponee.io (Postfix) with ESMTP id 06DF0180652 for ; Thu, 1 Feb 2018 14:05:09 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id EB25B160C44; Thu, 1 Feb 2018 13:05:08 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 3D2A9160C26 for ; Thu, 1 Feb 2018 14:05:08 +0100 (CET) Received: (qmail 82212 invoked by uid 500); 1 Feb 2018 13:05:07 -0000 Mailing-List: contact commits-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list commits@cloudstack.apache.org Received: (qmail 82203 invoked by uid 99); 1 Feb 2018 13:05:07 -0000 Received: from ec2-52-202-80-70.compute-1.amazonaws.com (HELO gitbox.apache.org) (52.202.80.70) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Feb 2018 13:05:07 +0000 From: GitBox To: commits@cloudstack.apache.org Subject: [GitHub] rafaelweingartner opened a new pull request #2443: [CLOUDSTACK-9338] ACS not accounting resources of VMs with custom service offering properly Message-ID: <151749030682.5118.4051371498706136501.gitbox@gitbox.apache.org> rafaelweingartner opened a new pull request #2443: [CLOUDSTACK-9338] ACS not accounting resources of VMs with custom service offering properly URL: https://github.com/apache/cloudstack/pull/2443 ## Description ACS accounts the resources when deploying VMs with custom service offerings. However, there are other methods (such as updateResourceCount) that do not execute the resource accounting properly, and these methods update the resource count for an account in the database. Therefore, if a user deploys VMs with custom service offerings, and later this user calls the ?updateResourceCount? method, it (the method) will only account for VMs with normal service offerings, and update this as the number of resources used by the account. This will result in a smaller number of resources to be accounted for the given account than the real used value. The problem becomes worse because if the user starts to delete these VMs, it is possible to reach negative values of resources allocated (breaking all of the resource limiting for accounts). This is a very serious attack vector for public cloud providers! ## Steps to reproduce: 1. Create a new account and dedicate some resources to it 2. Instantiate a VM using a custom service offering 3. Check the CPU and memory resource count for the given VM (the count must be correct at this point): select * from resource_count where account_id = ? 4. Go to the details of the account and click on ?Update resource count? 5. Execute the SQL again (select * from resource_count where account_id = ?), and check if the resource count is correct. The value of resource count will consider only VMs deployed with normal service offering; 6. Delete all VMs 7. Check the resource count table again. It will reach negative values. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: users@infra.apache.org With regards, Apache Git Services