-
-
Notifications
You must be signed in to change notification settings - Fork 348
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
OPL: Incorrect Evaluation of Permissions in Ory Keto #1522
Comments
I encountered a similar problem when using hierarchical checks (a if permit c, c if permit d, d if ID in owners). FYI: There was no '!' in any of the OPL rules, so my issue was not related to that. |
Hi, and thanks for the report. Unfortunately I could not reproduce this yet. Please see my attempt here: I get the correct check result as per the instructions you posted, but I failed to rearrange the expressions such that the check would be false. Can you post exactly how you modified the OPL? |
@rbnbr please also provide a reproducer of the bug you discovered. A PR with a failing test would be highly appreciated (they are quite nice to write if you know Go), but I can also follow your instructions if you post the OPL, tuples and checks. Big thanks in advance! |
@hperl I'll take a look after work and try to produce the bug again and come up with the PR as requested. Also since you're here, I'd like to note that the "!" Is not officially supported by the documentation afaik https://www.ory.sh/docs/keto/reference/ory-permission-language |
You're right! Fix is here: #1530 |
So I was able to recreate the (what I believe to be) bug. I added a pull request but the tests couldn't be properly executed on my machine. Maybe I used the wrong commands? Using the OPL as described in this file with the following tuples:
The following is returned when checked with the CLI:
Which is (imo) weird since the
|
Thanks @rbnbr for the testcase! The behaviour you encountered comes from the fact that the default depth (the number of hops we take to check access) is 5, which is exactly one too short for correctly checking @zepatrik maybe we should handle "depth depletion" in a more obvious way, i.e. by returning an error, or even better by returning the queries where the check stopped, so that the check can be resumed from those queries. This would then work like tree traversal pagination. WDYT? @LukaGiorgadze, is your issue maybe also related to the read depth limit? |
Thank you, @hperl, for looking into that. I also thought the depth might be the issue, though; when I added the So, the results with the CLI do not change if I add the depth parameter:
|
You also need to set the max in the configuration. |
Oh, right. Great! Thanks for pointing it out, I missed that part. So it's no bug after all then :) |
Preflight checklist
Ory Network Project
No response
Describe the bug
When evaluating user permissions in Ory Keto, a discrepancy occurs based on the order of user group checks. When a user is only in the "owners" group, the expected behavior is to return
True
for theitemView
perm. However, when the linethis.related.owners.includes(ctx.subject)
is moved up in the code block, while keeping the rest of the logic identical, the function incorrectly returnsFalse
. This issue arises despite the fact that the code remains technically the same.This discrepancy manifests when incorporating a check for blocked users, denoted by
!this.related.blockedUsers.includes(ctx.subject) && ()
. The unexpected behavior undermines the intended functionality of permission evaluation and could potentially lead to incorrect access control decisions.Reproducing the bug
Relevant log output
No response
Relevant configuration
No response
Version
v0.11.1-alpha.0
On which operating system are you observing this issue?
macOS
In which environment are you deploying?
Docker Compose
Additional Context
No response
The text was updated successfully, but these errors were encountered: