threshold-oriented alarm created by admin on behalf of non-admin user:tenant leaks admin-level visibility on statistics

[Eoghan Glynn]

When an admin creates a threshold-oriented alarm on behalf of an non-admin user, this has the effect of leaking visibility onto statistics for resources that would not normally be visible to the non-admin user.

An example scenario:

 1. ADMIN creates instance with INSTANCE_ID
 2. ADMIN creates alarm ALARM1 with --user DEMO --project DEMO --matching-metadata resource_id=$INSTANCE_ID
 3. DEMO creates alarm ALARM2 with --matching-metadata resource_id=$INSTANCE_ID
 4. ALARM1 ==> ok or alarm
 5. ALARM2 ==> insufficient_data

whereas both alarms should transition to insufficient_data, seeing as the instance stats should not be visible to the DEMO user.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/50708
Committed: http://github.com/openstack/ceilometer/commit/7ee6f6d29451be4f2c9d5146e4cfbc147f33ee04
Submitter: Jenkins
Branch: master

commit 7ee6f6d29451be4f2c9d5146e4cfbc147f33ee04
Author: Eoghan Glynn <email address hidden>
Date: Wed Oct 9 19:34:00 2013 +0100

    Avoid leaking admin-ness into threshold-oriented alarms

    Fixes bug 1237567

    Previously when an admin created a threshold-oriented alarm on
    behalf of an non-admin identity, this had the effect of leaking
    visibility onto statistics for resources that would not normally
    be visible to the non-admin tenant.

    Now we ensure that an additional implicit threshold rule query
    constraint is added on the project ID of the non-admin indentity
    that will ultimately own the alarm.

    This is acheived by splitting the query validation from the
    construction of the kwargs from the query. The addition of the
    implicit query constraint to the threshold rule can then be
    delayed to a later point in the dispatch path where the full
    context of the alarm is known (so that we can check for the case
    where the alarm is created by an admin on behalf of another tenant).

    Change-Id: I1adae8c899112e7c3eb4e94f3f68262c84a98574

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: milestone-proposed
Review: https://review.openstack.org/51296

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/51296
Committed: http://github.com/openstack/ceilometer/commit/878a329cf7aae58b72f7fdd16fad4cf5c8b49277
Submitter: Jenkins
Branch: milestone-proposed

commit 878a329cf7aae58b72f7fdd16fad4cf5c8b49277
Author: Eoghan Glynn <email address hidden>
Date: Wed Oct 9 19:34:00 2013 +0100

    Avoid leaking admin-ness into threshold-oriented alarms

    Fixes bug 1237567

    Previously when an admin created a threshold-oriented alarm on
    behalf of an non-admin identity, this had the effect of leaking
    visibility onto statistics for resources that would not normally
    be visible to the non-admin tenant.

    Now we ensure that an additional implicit threshold rule query
    constraint is added on the project ID of the non-admin indentity
    that will ultimately own the alarm.

    This is acheived by splitting the query validation from the
    construction of the kwargs from the query. The addition of the
    implicit query constraint to the threshold rule can then be
    delayed to a later point in the dispatch path where the full
    context of the alarm is known (so that we can check for the case
    where the alarm is created by an admin on behalf of another tenant).

    Change-Id: I1adae8c899112e7c3eb4e94f3f68262c84a98574
    (cherry picked from commit 7ee6f6d29451be4f2c9d5146e4cfbc147f33ee04)