Expand does not include userset rewrites
rdurell opened this issue · comments
Preflight checklist
- I could not find a solution in the existing issues, docs, nor discussions.
- I agree to follow this project's Code of Conduct.
- I have read and am following this repository's Contribution Guidelines.
- This issue affects my Ory Cloud project.
- I have joined the Ory Community Slack.
- I am signed up to the Ory Security Patch Newsletter.
Describe the bug
Using the data from the userset-rewrites example, the expand route does not include implicit tuples from defined by the userset rewrites. A check command will return "Allowed" but the corresponding expand command returns an empty tree.
Reproducing the bug
Note: You may need to include --insecure-disable-transport-security flag for the commands below.
- Load the tuple data referenced from the userset-rewrites example
- Run "keto relation-tuple get" and ensure the output is as follows:
NAMESPACE OBJECT RELATION NAME SUBJECT
Folder keto/ viewers Group:developer#members
Folder keto/src/ parents Folder:keto/
File private owners User:Henning
Group developer members patrik
Group developer members User:Henning
File keto/src/main.go parents Folder:keto/src/
File keto/README.md parents Folder:keto/
Group developer members User:Patrik
- Run "keto check User:Henning edit File private"
Note the output is "Allowed" - Run "keto expand edit File private"
Note the output is "Got an empty tree. This probably means that the requested relation tuple is not present in Keto."
Expected -- The tree would include some implicit tuple representing the rewrite. - Run "keto expand owners File private"
Note that the output includes the explicit tuple loaded from the sample data:
or :#@file:private#owners
└──∋ :#@user:Henning️
Relevant log output
No response
Relevant configuration
No response
Version
0.10.0-alpha.0
On which operating system are you observing this issue?
Linux
In which environment are you deploying?
Binary
Additional Context
No response
yup I'm struggling to understand the subject-set rewrites for precisely this reason. The permits
attribute of the namespace configuration seem to allow you to specify subjet-set rewrites. That the permits
section is effectively the subject-set rewrite feature is also not well explained in my opinion. I couldn't build that bridge in my mind, until I read the original paper. But back to the point, the edit
permission is effectively a relation and in my opinion should be represented by an edge in the tree of the flattened DAG. Which is what the expand command should be doing no?
I wonder if this rationale should also apply to the List API.
If the permits
section is "just" a way to define a relation
using subject-set rewrites. Then supporting the subject-set rewrites for both the expand and list endpoint's relation
argument would be consistent right?
But yes, would love to see this feature 👍 since as it stands the only workarounds appear to be:
- Duplicate your understanding of the rewrites in your application, by listing the normal relationships instead.
- Do a large number of check queries for each potential tuple.