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).
Reviewed: https:/ /review. openstack. org/50708 github. com/openstack/ ceilometer/ commit/ 7ee6f6d29451be4 f2c9d5146e4cfbc 147f33ee04
Committed: http://
Submitter: Jenkins
Branch: master
commit 7ee6f6d29451be4 f2c9d5146e4cfbc 147f33ee04
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: I1adae8c899112e 7c3eb4e94f3f682 62c84a98574