https://authzed.com logo
Join Discord
Powered by
This works, however the complexity of
# spicedb
a
This works, however the complexity of maintaining and reading through the permissions is becoming error-prone, wish there was a better way, I'm just demoing stuff and can barely understand it anymore 😅 I'm still hitting max depth, not sure why, well I guess because propagating up and down, across several permissions and within 1 folder 1 subfolder and 1 doc it hits the max, https://play.authzed.com/s/SJRaU2OqtBKi/schema If this is the case I have no idea how to design it.
v
The requirements describe a cyclic graph, hence the suggestion to define permissions that traverse in one direction or the other, so it is turned into an acyclic graph. I'm curious to hear the use-case. Granting permission to a document which then implicitly gives permission to all sibling document/folders is not very common. As SpiceDB dispatches through the graph, it's unable to keep the context of what has been traversed, so the max depth is set as a means to prevent recursively looping forever. Recently a bloom filter was introduced to prevent recursion deadlock in the single-flight dispatch middleware. This worked for single-flight because if a false positive is found, it will just cause the request no to be singleflighted. Eventually the max-depth limit would trigger if it was indeed a recursion. If we were able to represent an ObjectType+ObjectID+Relation triple as an integer, we could efficiently represent the traversal context as a roaring bitmap and propagate that as part of the dispatch metadata. This would effectively remove the need for max depth and make your use-case easier to model. cc @Joey We've been discussing a way to uniquely identify those triples, but it is a non-trivial database migration.
the loop is almost certainly happening when you traverse via 
location->view_up
. The recursion is introduced via 
view_self = edit + reader
, as 
edit
causes the traversal of the folder to start moving down to children, which will find the same document that initiated the traversal. A way to solve this is to not create the "joint" permission, only up and down permissions, and then use 
BulkCheckPermission
to always send 2 checks, one in one direction, and the other in the other direction.
a
> I'm curious to hear the use-case. Granting permission to a document which then implicitly gives permission to all sibling document/folders is not very common. I'm proposing something very similar to a filesystem, and I'm thinking from the UX backwards. I have folders and subfolders, the docs at any given depth. If adrian creates the structure /foo/bar/document When he wants to give read access to the document to vroldanbet, he probably implicitly expects that he will be able to browse the path that the document lives on. Otherwise when vroldanbet visits adrian site, he won't be able to see anything, but if he somehow manages to type the full path, he will be granted access. Which means it's unexpected = bad ux. I can circumvent this via different application UX designs, or just make sure that when adrian grants permissions to the document he also unbeknownst to him, is granting reading permission to /foo and /bar, but this can get messy, but ideally, all authz logic resides in one place, hence why I am asking.
Mind you in the case I'm showing you, even if I had more adjent documents inside /foo/bar/document_2 vroldanbet won't be able to see them, unless given folder access
After re-reading I'm still not following what you mean.
v
So is the proposed UX to have vroldanbet click through, say, folders, until reaching the shared document?
What do the access patterns in terms of spicedb checks looks like in this scenario? Typically you check the resource being accessed, so I wonder if you are planning lookup resources to enumerate all resources at a given level, or are planning to issue individual checks for children in each level
I'm assuming top-down navigation, as you mentioned, just like a file system
This is an example where I made the traversal strict and removed loops: https://play.authzed.com/s/jV4MkQEGBnM6/schema
This is what the downward navigation looks like. 
user:someone
has access to 
folder:foo
because they have access to one of foo indirect children
Copy code
zed permission check folder:foo view_down user:someone --explain
true
✓ folder:foo view_down (11.2ms)
├── ✓ folder:bar view_down (6.4ms)
│   ├── ✓ document:x view_down (3.2ms)
│   │   └── ✓ document:x reader (99.84µs)
│   │       └── user:someone 
│   └── ⨉ folder:bar reader (99.84µs)
├── ⨉ folder:foo reader (99.84µs)
└── ⨉ folder:foo edit_down (9.900032ms)
    ├── ⨉ folder:bar edit_down (4.499968ms)
    │   ├── ⨉ document:x edit_down (699.904µs)
    │   │   ├── ⨉ document:x editor (0s)
    │   │   └── ⨉ document:x admin_down (300.032µs)
    │   │       ├── ⨉ document:x owner (100.096µs)
    │   │       └── ⨉ document:x adminer (99.84µs)
    │   ├── ⨉ folder:bar editor (0s)
    │   └── ⨉ folder:bar admin_down (1.6ms)
    │       ├── ⨉ document:x admin_down (300.032µs)
    │       │   ├── ⨉ document:x owner (0s)
    │       │   └── ⨉ document:x adminer (0s)
    │       ├── ⨉ folder:bar owner (0s)
    │       └── ⨉ folder:bar adminer (0s)
    ├── ⨉ folder:foo editor (100.096µs)
    └── ⨉ folder:foo admin_down (5.999872ms)
        ├── ⨉ folder:bar admin_down (5.199872ms)
        │   ├── ⨉ document:x admin_down (1.299968ms)
        │   │   ├── ⨉ document:x owner (100.096µs)
        │   │   └── ⨉ document:x adminer (0s)
        │   ├── ⨉ folder:bar owner (0s)
        │   └── ⨉ folder:bar adminer (0s)
        ├── ⨉ folder:foo owner (100.096µs)
        └── ⨉ folder:foo adminer (0s)
unfortunately 
--explain
does not seem to show the traversed path when there is recursion, even when the error message itself suggests to use 
--explain
, that seems unexpected. If it did, it would show how you are going from 
document
back to parent 
folder
and then again to child 
document
, which recurses until reaching max depth limit of 50
a
yes
access patterns: - when you arrive at my site(root folder) you can see /foo - when you arrive at my site(root folder) you can see/search all available content even in subfolders - when you access directly /foo/bar/document you can read the document directly.
In my case it's a bit trickier, because yes, I plan to allow a normal filesystem type of access but also a flattened browsing pattern, so you could(and this is by default) when browsing my site, see the document that's inside /foo/bar without having to go there. and when you browse /foo you only see anything below foo. This can be disabled.
I know it's unorthodox and may seem odd, but I really like it, can share more details when I build it
So if I understand this correctly, if I wanted to proceed like this I should perform 2 checks(or 1 if first grants access), right?
v
you can proceed with a bulk check that does the 2 checks. Internally SpiceDB does clever tricks to reuse as many subproblems as possible
and I hope I didn't come across as judging the proposed UX, my priority is to support y'all in your SpiceDB journey. Sometimes I need to help to understand the requirements 😄
a
Oh nono, no worries, I didn't feel judged, I'm still learning, plus I'm aware I'm proposing unorthodox things, so I totally get the question and I appreciate your help 🙂
59 Views
PreviousNext
Powered by