<div dir="ltr"><div><div><div><div><div>Hi,<br><br></div>I noticed that the Ceilometer project has no strict policy control, the /etc/ceilometer/policy.json only has one single rule 'context_is_admin', and for each specific resource operation, it will invoke acl.get_limit_to and v2._verify_query_segregation to forbid non-admin role operate other tenant's resources, so normal user has full privilege to CURD all resources in his own tenant, which means it can delete the alarms which is created by other users (verified in deployed Havana environment), this sounds not so good.<br>
<br></div>So, is this loose policy limit designed purposely, or it just a simple implementation for policy?<br><br></div>In other core projects (except heat), for i.e. Neutron, policy is very detailed, resource operation policy even can forcus on an attribute. And the verification is not defined in specific operation's code but call a function and it will check the rules defined in policy.json.<br>
<br></div>So, is there any opportunity to implement more strict policy check, for i.e. a normal user can read resources created by other users (to be stricter, may disable this too), but read+write for his own?<br><br></div>
<div>I'd like to get some help or advise before create a blueprint<br></div><div><br></div>Thanks<br></div>