Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Singleton types for action hierarchy expressions #310

Closed
2 tasks
mwhicks1 opened this issue Sep 18, 2023 · 3 comments
Closed
2 tasks

Singleton types for action hierarchy expressions #310

mwhicks1 opened this issue Sep 18, 2023 · 3 comments
Labels
feature-request This issue requets a substantial new feature

Comments

@mwhicks1
Copy link
Contributor

mwhicks1 commented Sep 18, 2023

Category

Cedar validation features

Describe the feature you'd like to request

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
@mwhicks1 mwhicks1 added pending-triage The cedar maintainers haven't looked at this yet. Automicaly added to all new issues. feature-request This issue requets a substantial new feature labels Sep 18, 2023
@shaobo-he-aws 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
@john-h-kastner-aws
Copy link
Contributor

Some overlap with #105

@mwhicks1
Copy link
Contributor Author

Some overlap with #105

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.

@john-h-kastner-aws
Copy link
Contributor

Closing in favor of #105

@john-h-kastner-aws john-h-kastner-aws removed the pending-review A Cedar maintainer has looked at this, but believes it needs review by more of the core team label Nov 13, 2023
@sarahcec sarahcec moved this to Todo in Cedar 3.2 Status Nov 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request This issue requets a substantial new feature
Projects
None yet
Development

No branches or pull requests

3 participants