You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The validator should give expressions like Action::"getList" in Action::"listActions" type True and expressions like Action::"updateTask" in Action::"listActions" type False based on action hierarchy information kept in the schema, e.g., that Action::"getList" has Action::"listActions" as a parent (but Action::"updateTask" does not).
This can be important for short-circuiting. For example, suppose that I have a policy
permit(principal, action in Action::"listActions",resource)
when {
principal.owner == resource ||
resource.isPublic == true
}
Here we assume that listActions is meant to be used with List objects, and such objects have a isPublic attribute. But suppose we also have Task objects that don't have such an attribute. Then if we type check action Action::"updateTask" with a Task object as a resource, then when considering the above policy we will get a false alarm because after substituting Action::"updateTask" for action we will get action expression Action::"updateTask" in Action::"listActions" with type Boolean. Typechecking will proceed to the when clause and fail due to the missing attribute. Giving the action expression type False solves this issue.
Describe alternatives you've considered
You could manually add is List to the resource constraint once we support that.
Additional context
No response
Is this something that you'd be interested in working on?
👋 I may be able to implement this feature request
⚠️ This feature might incur a breaking change
The text was updated successfully, but these errors were encountered:
shaobo-he-aws
added
pending-review
A Cedar maintainer has looked at this, but believes it needs review by more of the core team
and removed
pending-triage
The cedar maintainers haven't looked at this yet. Automicaly added to all new issues.
labels
Sep 21, 2023
Can we merge this into #105 and close this one, once done?
I observe that #105 is not very prescriptive -- it enumerates a problem, but not the solution. You could steal some text from this issue and generalize it in that one.
Category
Cedar validation features
Describe the feature you'd like to request
The validator should give expressions like
Action::"getList" in Action::"listActions"
typeTrue
and expressions likeAction::"updateTask" in Action::"listActions"
typeFalse
based on action hierarchy information kept in the schema, e.g., thatAction::"getList"
hasAction::"listActions"
as a parent (butAction::"updateTask"
does not).This can be important for short-circuiting. For example, suppose that I have a policy
Here we assume that
listActions
is meant to be used withList
objects, and such objects have aisPublic
attribute. But suppose we also haveTask
objects that don't have such an attribute. Then if we type check actionAction::"updateTask"
with aTask
object as a resource, then when considering the above policy we will get a false alarm because after substitutingAction::"updateTask"
foraction
we will get action expressionAction::"updateTask" in Action::"listActions"
with typeBoolean
. Typechecking will proceed to thewhen
clause and fail due to the missing attribute. Giving the action expression typeFalse
solves this issue.Describe alternatives you've considered
You could manually add
is List
to theresource
constraint once we support that.Additional context
No response
Is this something that you'd be interested in working on?
The text was updated successfully, but these errors were encountered: