Max-depth not being applied correctly on check
mathieujohnson 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 Network project.
- I have joined the Ory Community Slack.
- I am signed up to the Ory Security Patch Newsletter.
Describe the bug
While having a high max_read_depth limit of 50, I don't get the expected check value from the cli or rest api. When I use expand I see the tree of relations and using max-depth works. While using check with the data from the expand command I don't get the expected allowed. When I use a relation that is 1 level less deep I get the expected result. Changing the max-depth argument for check doesn't change the result.
What is the issue here? Did I miss something while configuring?
Reproducing the bug
This is my setup:
/ $ keto relation-tuple get --read-remote 127.0.0.1:4466 --insecure-disable-transport-security
NAMESPACE OBJECT RELATION NAME SUBJECT
zone usa view site:site_2#view
observation observation_1 view site:site_1#view
site site_2 view client:shell#member
observation observation_3 view site:site_2#view
zone usa view site:site_1#view
client shell member mjohnson@ghgsat.com
observation observation_10 view zone:usa#view
observation observation_20 view zone:usa#view
observation observation_40 view zone:asia#view
client shell admin ceo1@shell.com
client shell member employee2@shell.com
observation observation_2 view site:site_1#view
site site_1 view client:shell#member
observation observation_30 view zone:asia#view
client shell member employee1@shell.com
client shell member client:shell#admin
observation observation_4 view site:site_2#view
NEXT PAGE TOKEN
IS LAST PAGE true
Keto expand gives me this:
/ $ keto expand view observation observation_10 --read-remote 127.0.0.1:4466 --insecure-disable-transport-security --max-depth 8
or :#@observation:observation_10#view
└──or :#@zone:usa#view
├──or :#@site:site_2#view
│ └──or :#@client:shell#member
│ ├──∋ :#@mjohnson@ghgsat.com️
│ └──∋ :#@employee2@shell.com️
│ └──∋ :#@employee1@shell.com️
│ └──or :#@client:shell#admin
│ └──∋ :#@ceo1@shell.com️
└──or :#@site:site_1#view
└──∋ :#@client:shell#member️
and using check doesn't seem to match:
/ $ keto check employee2@shell.com view observation observation_10 --read-remote 127.0.0.1:4466 --insecure-disable-transport-security --max-depth 8
Denied
even with higher max-depth values:
/ $ keto check employee2@shell.com view observation observation_10 --read-remote 127.0.0.1:4466 --insecure-disable-transport-security --max-depth 9
Denied
/ $ keto check employee2@shell.com view observation observation_10 --read-remote 127.0.0.1:4466 --insecure-disable-transport-security --max-depth 10
Denied
But going one level less deep I get a positive result:
/ $ keto check client:shell#member view observation observation_10 --read-remote 127.0.0.1:4466 --insecure-disable-transport-security --max-depth 8
Allowed
Relevant log output
No response
Relevant configuration
version: v0.11.0
log:
level: trace
namespaces:
- id: 0
name: client
- id: 1
name: observation
- id: 2
name: zone
- id: 3
name: site
dsn: memory
limit:
max_read_depth: 50
serve:
read:
host: 0.0.0.0
port: 4466
write:
host: 0.0.0.0
port: 4467Version
v0.11.0-alpha.0
On which operating system are you observing this issue?
Linux
In which environment are you deploying?
Docker Compose
Additional Context
No response
Hi,
I encounter too this bug. In previous version (0.10) I was getting randomly allowed true or false.
Since update to v0.11, it is more determinist, but I get always false.
Starting max-depth > 2, it does not work (allowed = false).
Expand is outputing also the correct tree in my case.
If that can help.
echo "
log:
level: trace
namespaces:
- id: 0
name: client
- id: 1
name: observation
- id: 2
name: zone
- id: 3
name: site
dsn: memory
limit:
max_read_depth: 50
" > keto.yml
go run -tags sqlite . serve -c keto.yml &
echo "zone:usa#view@site:site_2#view
observation:observation_1#view@site:site_1#view
site:site_2#view@client:shell#member
observation:observation_3#view@site:site_2#view
zone:usa#view@site:site_1#view
client:shell#member@mjohnson@ghgsat.com
observation:observation_10#view@zone:usa#view
observation:observation_20#view@zone:usa#view
observation:observation_40#view@zone:asia#view
client:shell#admin@ceo1@shell.com
client:shell#member@employee2@shell.com
observation:observation_2#view@site:site_1#view
site:site_1#view@client:shell#member
observation:observation_30#view@zone:asia#view
client:shell#member@employee1@shell.com
client:shell#member@client:shell#admin
observation:observation_4#view@site:site_2#view" | go run . relation-tuple parse --format json - | go run . relation-tuple create - --insecure-disable-transport-security --write-remote "127.0.0.1:4467"
go run . check employee2@shell.com view observation observation_10 --read-remote 127.0.0.1:4466 --insecure-disable-transport-security --max-depth 3
# returns denied
go run . check employee2@shell.com view observation observation_10 --read-remote 127.0.0.1:4466 --insecure-disable-transport-security --max-depth 4
# returns allowed
go run . check ceo1@shell.com view observation observation_10 --read-remote 127.0.0.1:4466 --insecure-disable-transport-security --max-depth 4
# returns denied
go run . check ceo1@shell.com view observation observation_10 --read-remote 127.0.0.1:4466 --insecure-disable-transport-security --max-depth 5
# returns allowedI cannot reproduce your example on master, but I can reproduce it on v0.11.0
IMO this was fixed by #1256. I will schedule a new release v0.11.1 now that includes that fix. I will close this issue once the release is out.