We already have this for policies that evaluate to false, and a policy that always applies is potentially more problematic.
E.g.,
permit(principal, action, resource);
is always true, so we should return a warning
A slightly complex example might be
forbid(principal, action == Action::"view", resource) when {
principal != Group::"jane-family"
};
When the view action applies to users and not groups.
Note that, like the warning for false policies, this does not aim to be a sound analysis. There will be many policies that are always true which we will not detect (without using our SMT based analysis tools).
Two possible concerns:
Users who want to emulate default-allow in Cedar might intentionally include a policy permit(principal, action, resource);. but the proposed change is a warning, so they can freely ignore it.
We encourage users to write multiple simple policies, but the proposed change would not detect a set of policies which together always evaluate to at least one true. This isn't necessarily a problem because the proposed warning does not aim to be sound, but it would lead to some mistakes we should be able to notice being missed when split between policies. The might instead be run against the disjunction of all policy expressions, short-circuiting is a problem here because || short-circuits on true, but policy evaluation does not.
Describe alternatives you've considered
.
Additional context
No response
Is this something that you'd be interested in working on?
[ ] 👋 I may be able to implement this feature request
Related to #103. Implementing that issue would very mean doing this one at the same time, but this issue is substantially simpler, taking a day or two rather than up to a week or two.
Category
Cedar validation features/changes
Describe the feature you'd like to request
We already have this for policies that evaluate to
false
, and a policy that always applies is potentially more problematic.E.g.,
is always true, so we should return a warning
A slightly complex example might be
When the
view
action applies to users and not groups.Note that, like the warning for
false
policies, this does not aim to be a sound analysis. There will be many policies that are alwaystrue
which we will not detect (without using our SMT based analysis tools).Two possible concerns:
permit(principal, action, resource);
. but the proposed change is a warning, so they can freely ignore it.true
. This isn't necessarily a problem because the proposed warning does not aim to be sound, but it would lead to some mistakes we should be able to notice being missed when split between policies. The might instead be run against the disjunction of all policy expressions, short-circuiting is a problem here because||
short-circuits ontrue
, but policy evaluation does not.Describe alternatives you've considered
.
Additional context
No response
Is this something that you'd be interested in working on?