normal user create alarm with user-id or project-id specified will success instead of return 401

If that's true, that's a serious problem, but I doubt it is, _unless_ you're admin.

reproduce steps:

$ ./rejoin-stack.sh
$ nova-manage version
2014.1
$ . accrc/demo/demo
$ ceilometer --debug alarm-threshold-create --name demo-test-alarm --meter instance --threshold 1 --user-id non-existent-user --project-id non-existent-project
+---------------------------+--------------------------------------------------------+
| Property | Value |
+---------------------------+--------------------------------------------------------+
| alarm_actions | [] |
| alarm_id | bfa5d625-019c-4f34-b31c-d4cfba3bae1f |
| comparison_operator | eq |
| description | Alarm when instance is eq a avg of 1.0 over 60 seconds |
| enabled | True |
| evaluation_periods | 1 |
| exclude_outliers | False |
| insufficient_data_actions | [] |
| meter_name | instance |
| name | demo-test-alarm |
| ok_actions | [] |
| period | 60 |
| project_id | 9cfec11acb784976a6769bcdea9ef8b6 |
| query | project_id == 9cfec11acb784976a6769bcdea9ef8b6 |
| repeat_actions | False |
| state | insufficient data |
| statistic | avg |
| threshold | 1.0 |
| type | threshold |
| user_id | 9eb237a9687d4216a430393352461def |
+---------------------------+--------------------------------------------------------+
$ . accrc/admin/admin
$ keystone user-get demo
+----------+----------------------------------+
| Property | Value |
+----------+----------------------------------+
| email | <email address hidden> |
| enabled | True |
| id | 9eb237a9687d4216a430393352461def |
| name | demo |
| tenantId | 9cfec11acb784976a6769bcdea9ef8b6 |
| username | demo |
+----------+----------------------------------+

I was able to reproduce the problem.

I also tried with the admin user. With that user I can set any kind of valid and invalid user and project_id. I agree that admin should be able to set any valid user and project_id for an alarm but I think we should not allow invalid or nonexistent user and project_id to be set even by the admin user.

What do you think?

+---------------------------+--------------------------------------------------------+
| Property | Value |
+---------------------------+--------------------------------------------------------+
| alarm_actions | [] |
| alarm_id | 51e759ca-258a-4efc-a614-774153c434e7 |
| comparison_operator | eq |
| description | Alarm when instance is eq a avg of 1.0 over 60 seconds |
| enabled | True |
| evaluation_periods | 1 |
| exclude_outliers | False |
| insufficient_data_actions | [] |
| meter_name | instance |
| name | demo-test-alarm |
| ok_actions | [] |
| period | 60 |
| project_id | non-existent-project |
| query | project_id == non-existent-project |
| repeat_actions | False |
| state | insufficient data |
| statistic | avg |
| threshold | 1.0 |
| type | threshold |
| user_id | non-existent-user |
+---------------------------+--------------------------------------------------------+

Just throwing a WIP patch with a potential fix out there:

  https://review.openstack.org/83072

@ ZhiQiang Fan: if you already have a fix in the works that could land for icehouse-rc1, I'll abandon mine.

Cheers,
Eoghan

@ZhiQiang Fan: I'll take this bug is that's OK, as RC1 is getting very close (due to be cut Friday).

Cheers,
Eoghan

sure, go ahead
I have other fires to be put out

at first glance, I thouht this is a low level bug or user experience problem

Reviewed: https://review.openstack.org/83072
Committed: https://git.openstack.org/cgit/openstack/ceilometer/commit/?id=e538f84cfe8ef4f63c854a9b258c367d254a667b
Submitter: Jenkins
Branch: master

commit e538f84cfe8ef4f63c854a9b258c367d254a667b
Author: Eoghan Glynn <email address hidden>
Date: Wed Mar 26 11:13:23 2014 +0000

    Verify user/project ID for alarm created by non-admin user

    Fixes bug 1297677

    Previously, when a non-admin user created an alarm on behalf of
    another user, the ownership of the alarm silently reverted to the
    requestor's identity.

    Now, we check for this case and fail with 401 Not Authorized when
    a non-admin user attempts to create an alarm explicitly associated
    with another identity.

    Change-Id: I8f372b1523012990b8f1d48b03cf9ed9cef65c60

when I verify this problem today, I find that the alarm-update has the same problem, but we all forget to consider this issue.

Should I create another bug?