https://authzed.com logo
Join Discord
Powered by
The main advantage is that I don't need to create ...
# spicedb
l
The main advantage is that I don't need to create a hostX_PortY object for every potential port and host (and there could be lots of them) to handle the super user case. And this could potentially be a scale killing cross product
Just continuing in a separate thread
j
yeah
l
And by keeping the host and the port separate I would need to do two checks - something I would like to avoid
I don't expect frequent schema updates to add permissions for specific ports, but it will happen off and on. I also don't expect the number of specific port permission to be a large number.
j
yeah, the standard way to do this would be to have a 
definition hostport
and link all the objects
so in your default permission idea
when does the fallback occur?
(just trying to get a handle on the idea)
l
when spicedb cannot match the permission in the check request to a specific permission in the resource's schema AND there is a default permission defined in the schema
The schema would look some what like
Copy code
definition host {
  relation port8080_users: user
  relation port80_users: user
  relation port23_users: user
  relation port1345_users: user
  relation super_user: user
  permission can_access_port8080 = port8080_users + super_user
  permission can_access_port80 = port80_users + super_user
  permission can_access_port23 = port23_users + super_user
  permission can_access_port1345 = port1345_users + super_user
  permission default = super_user
}
modified the specific permissions to handle the super_user
@Joey not trying to be pesky. I am just pinging to keep the thread from being archived.
j
it archives after 2 weeks
so you have time
hmm
looks like we changed it to 3 days
n/m; carry on 🙂
l
It was 1 day by default 🙂 I set it to 3 days
j
ah
so the one concern I have about the default permission handling is that it would be super easy to typo a permission
you do 
can_acess_port23
and suddenly its checking the wrong thing
l
that's fine, if the user is a super user it wouldn't matter anyway. If the user is not a super user, then access would be denied because the typo would prevent a specific permission from getting matched. If the typo, is such that it presents a complete different permission in the check request, then its a bug 🙂
j
sure, in your schema is fine
its*
but I can imagine others where it might not be
l
Since the choice of using a default permission is up to the user of spicedb, this would be something they would need to consider. Much like the wildcard relation in the schema.
j
yeah
I'm just thinking through how to make it less foot-gun-ny
Next
Powered by