[murano] User can't upload package if someone else already uploaded package with the same name

[Anastasia Kuznetsova]

Steps to reproduce:
1. Create one more project for example for 'admin' user
2. Log in as 'admin' / 'admin', tenant 'admin'
3. Import app package
4. Switch to another tenant
5. Check list of applications (user shouldn't see packages uploaded under another tenant)
6. Try to import the same package

Observed result:
Error message that package with this name already exist, while user in this tenant doesn't see any packages

[Alexander Tivelkov (ativelkov)]

Targetting this to rc, as this is a critical issue

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/172905
Committed: https://git.openstack.org/cgit/stackforge/murano/commit/?id=f2ba54b62ba52d9079cb986f6efc8fd22f55b29b
Submitter: Jenkins
Branch: master

commit f2ba54b62ba52d9079cb986f6efc8fd22f55b29b
Author: Alexander Tivelkov <email address hidden>
Date: Mon Apr 13 15:52:38 2015 +0300

    A Galera-compliant database locking solution

    A common scenario in database interaction is to check some values in
    database and update them if some condition is met (or is not met). To
    prevent race conditions in such scenarios it is recomended to isolate
    appropriate transactions at read level, so two "select" operations are
    not executed in parallel. This may be achieved either by modifying
    transaction_isolation_level or by doing "selects" with a "for update"
    keyword, which puts a lock on the entries being selected thus blocking
    any other selects which may run in parallel transaction.

    The problem is that SELECT FOR UPDATE is not fully supported in Galera
    clusters which are a common tool for building HA openstack environments.
    Such statements may have non-determenistic results - see [1] for more
    details.

    This patch intoruduces a simple exclusive lock mechanics: it executes a
    simple insert or update operation into a special table. Any other
    transactions attempting to do the same will block until the first one
    completes in one way or another. This results in a simple but reliable
    locking solution, which may be not as effecient as dedicated distributed
    lock systems but still do its job nicely.

    Partial-bug: #1440094
    Change-Id: Ib606f33b832b04a3ecac27e1e10018ea8fd503a5

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/172015
Committed: https://git.openstack.org/cgit/stackforge/murano/commit/?id=f18661b586d486f276d1db980590bab3d607a578
Submitter: Jenkins
Branch: master

commit f18661b586d486f276d1db980590bab3d607a578
Author: Alexander Tivelkov <email address hidden>
Date: Thu Apr 9 14:08:05 2015 +0300

    Fix for cross-tenant package and class isolation

    The database constraints which were present were enforcing the global
    uniqueness of package FQNs and the names of classes defined in them.
    This behavior was not correct, as the uniqueness should be enforced per
    tenant, so the same package may be uploaded into two isolated tenants
    without affecting each other.

    This behavior lead to a very serious security issue: any tenant could
    upload a package, leave it private and thus block all other tenants of
    the cloud from uploading the package with the same name or even other
    packages which contain at least one class in common with it. This could
    be used to intentionally block all the operations of Murano on any
    public environments.

    This fix modifies the package name constraint to be unique only in
    combination with owner_id, i.e. makes packages unique per tenant. Also
    it removes the class name uniquness check from database (as there is no
    cross-DB way to check it in a proper way) and adds a check method in
    db.api module instead.

    As the packages may be made public, this introduces a potential
    collision: if the user owns some package, and there is a public package
    with the same fully-qualified-name (or defining same class(es)) then the
    class loader of the engine will have to choise between these packages
    and/or classes defined in them.
    To resolve this collision this commit adds a logic to fetch all the
    patching packages and then pick the best match. Packages owned by the
    current tenant are the most preferred, then the engine will pick public
    packages, and non-owned non-public packages are the least preferred
    (there may be no such packages now, they may appear when we add other
    ways of package sharing).

    Closes-bug: #1440094
    Change-Id: I5c9b49642dfb6e955cf0c98b42f418da3b82060a