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
Permissions questions in SpiceDB are answered by traversing the **tree** constructed from the graph formed
4
-
by combining the [schema] (structure) and [relationships] (data).
3
+
SpiceDB answers permissions questions by traversing a **tree** constructed from your [schema] (structure) and [relationships] (data).
5
4
6
-
A `CheckPermission` request will, for example, traverse starting from the resource+permission requested,
7
-
along any referenced permissions and relations, until the subject is found or maximum depth is
8
-
reached.
5
+
When you call `CheckPermission`, SpiceDB starts at the resource and permission you specified, then walks through relations and permissions until it either finds the subject or determines the subject doesn't have access.
9
6
10
7
[schema]: /spicedb/concepts/schema
11
8
[relationships]: /spicedb/concepts/relationships
12
9
13
-
## Max Depth
10
+
## How Traversal Works
14
11
15
-
In order to prevent requests from traversing without bounds, SpiceDB comes with a defaults to a depth of
16
-
`50`, after which computation is halted and an error is returned to the caller.
12
+
Consider this simple example:
17
13
18
-
This max depth is configurable via the `--dispatch-max-depth` flag.
14
+
```
15
+
┌─────────────────────┐
16
+
│ document:readme │
17
+
│ permission: view │
18
+
└─────────┬───────────┘
19
+
│ viewer relation
20
+
▼
21
+
┌─────────────────────┐
22
+
│ group:engineering │
23
+
│ permission: member │
24
+
└─────────┬───────────┘
25
+
│ member relation
26
+
▼
27
+
┌─────────────────────┐
28
+
│ user:alice │
29
+
└─────────────────────┘
30
+
```
31
+
32
+
When checking if `user:alice` can `view``document:readme`, SpiceDB traverses:
As we see above,`user:tom` is a `direct_member` of `secondgroup`, which makes him a member
96
-
of `firstgroup` -> which implies he's a member of `bannedgroup` -> which implies he's _not_
97
-
a member of `firstgroup` -> thus making him no longer `banned` -> (logical inconsistency)
123
+
SpiceDB does not have a dedicated cycle detector.
124
+
Instead, when a cycle exists, the traversal continues looping until it hits the **maximum depth limit**, then returns an error.
125
+
This same error occurs whether the cause is a cycle or simply a very deep (but acyclic) hierarchy.
98
126
99
-
Thus, to prevent the above issue from occurring, Zanzibar and other ReBAC implementations such
100
-
as SpiceDB assume the permissions graph is a [tree].
127
+
**Why not track visited objects?**
128
+
SpiceDB intentionally avoids tracking visited objects for two reasons:
101
129
102
-
[tree]: https://zanzibar.tech/2SMVg4W_Wx:N:k
130
+
1.**Semantic problems with self-referential sets**: When a group's members include itself, it creates logical paradoxes.
131
+
For example, if a user is a member through a cycle but also banned through the same cycle, is the user a member or not?
103
132
104
-
#### Overhead
133
+
2.**Performance overhead**: Tracking every visited object would require significant memory and network overhead, especially in distributed deployments.
105
134
106
-
From a practical perspective, tracking of visited objects when computing `CheckPermission` and
107
-
other permissions queries results in having significant amount of overhead over the wire and in
108
-
memory to track the full set of encountered objects and check for duplicates.
135
+
## Common Questions
109
136
110
-
### What do I do about a max depth error on CheckPermission?
137
+
### What do I do about a max depth error?
111
138
112
-
If you've received an error like:
139
+
If you see an error like:
113
140
114
141
```
115
142
the check request has exceeded the allowable maximum depth of 50: this usually indicates a recursive or too deep data dependency. Try running zed with --explain to see the dependency
116
143
```
117
144
118
-
Run`zed --explain`with the parameters of the check to show whether the issue is due to recursion or because the tree is simply too deep:
145
+
Use`zed permission check` with `--explain` to visualize the traversal path:
0 commit comments