Github user koushik-das commented on the pull request:
https://github.com/apache/cloudstack/pull/1489#issuecomment-214296336
@rhtyd My comment regarding the test was more in the context of perf. test.
In the DB for regular user I saw ~250 permissions got created. So this means
iterating over all these entries twice (ALLOW and DENY) to find a match and
then perform access check. There will be a perf. overhead due to this and user
should have an option to decide whether to use static or dynamic. Also if the
user finds some issues/bugs later during their testing there should be a
fallback option.
Regarding upgrade implications, I went through the docs/FS but some things
are still confusing. If existing user can continue using commands.properties
then what happens to the new APIs that gets added. If the argument is that the
permission can be put in as an annotation in code for new APIs then that
removes the flexibility of the earlier mechanism (there is no way to modify the
default in code). We don't know how people are customising commands.properties
and removing the flexibility may not be a good idea.
The question is not about advantage of static checker, but more about
choice and stability of the new mechanism.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
