844600078504951838 #spicedb

Channels

Jake

10/28/2021, 8:27 PM

version: "3.8"
services:
  db:
    image: postgres:9.4
    volumes:
      - db-data:/var/lib/postgresql/data
    networks:
      - backend
    environment:
      - POSTGRES_PASSWORD
    ports:
      - "5432:5432"
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5

Sleipnir

10/28/2021, 8:27 PM

Hrm

Jake

10/28/2021, 8:28 PM

when we switched over to k8s though, we made things much more crash-loop friendly

Jake

10/28/2021, 8:28 PM

which I don't think is a pattern compose works with

Sleipnir

10/28/2021, 8:29 PM

So this is what I see when I try that:

✅ spicedb-sync-poc % docker-compose up
ERROR: The Compose file './docker-compose.yml' is invalid because:
services.spicedb.depends_on contains {"psql": {"condition": "service_healthy"}}, which is an invalid type, it should be a string
❌ 1 spicedb-sync-poc %

Jonathan Whitaker

10/28/2021, 9:06 PM

Is there any interest in providing a terraform provider for schema management? I'm thinking that teams could define terraform resources describing the namespace schema definitions for the namespaces they own. It would just integrate with the v1.SchemaService API. Thoughts?

user

10/28/2021, 9:56 PM

yep, i actually had the terraform provider as a showerthought for an issue internally

user

10/28/2021, 9:56 PM

you could even provision databases from authzed.com via terraform

Jonathan Whitaker

10/28/2021, 10:20 PM

Yep, love that idea 🙂

Jonathan Whitaker

10/28/2021, 10:39 PM

I have a schema that looks like this:

definition user {}

definition group {
    relation member: user | group#member
}

definition portfolio {
    relation owner: user
    relation viewer: user | portfolio#editor | group#member
    relation editor: user | portfolio#owner | group#member

    permission view = viewer
    permission edit = editor
}

I write a relation and then subsequently read a relation. Here's the read that I get back:

{
  "readAt": {
    "token": "GgMKATQ="
  },
  "relationship": {
    "relation": "owner",
    "resource": {
      "objectId": "1",
      "objectType": "portfolio"
    },
    "subject": {
      "object": {
        "objectId": "jonwhit",
        "objectType": "user"
      }
    }
  }
}

If I do a

check(portfolio:1, view, user:jonwhit)

I get

PERMISSIONSHIP_NO_PERMISSION

. Shouldn't that user have the permission since he is an owner and owners are editors and editors can view?

Jonathan Whitaker

10/28/2021, 10:41 PM

Using the memdb storage engine ^^

ecordell

10/28/2021, 10:55 PM

It looks like you want to include more relations in the permission, like:

permission view = viewer + editor + owner
permission edit = editor + owner

To clarify, when you write a relation like this:

relation editor: user | portfolio#owner | group#member

What you're saying is "Let (spicedb) users write relationships for this namespace where the subject is a user, or the subject is an owner of a portfolio or the subject is a member of a group" - but those relationships still need to be written into the db by someone (you)

permissions

are what let you compute over relationships, which is probably what you were going for:

permission view = viewer + editor + owner

This says "we'll pretend there's a

view

relationship between resource and the subject if there's a relationship that says the subject is a viewer, editor, or owner of the resource"

Jonathan Whitaker

10/28/2021, 11:16 PM

Interesting. That's kind of confusing. Isn't the point of a rewrite to rewrite a relation definition in terms of another relation definition? So if I wanted to say anyone who has the editor relation also has the viewer relation I can't do that. I have to redefine that relationship in terms of the "computed" permission sets. Is that correct?

Joey

10/28/2021, 11:48 PM

Permissions are rewrites

Joey

10/28/2021, 11:48 PM

relations are non-rewrites

Joey

10/28/2021, 11:49 PM

The relations on the right side of a relation after the colon are types

Joey

10/28/2021, 11:52 PM

You wouldn’t say anyone who has editor is also a viewer; you’d say anyone who is an editor or viewer can view

jon-whit

10/29/2021, 12:33 AM

Gotcha. I think it’s just the structure that is confusing me. That makes sense though. Thanks guys

RNDude

10/29/2021, 7:09 AM

Following up on what you guys discussed, is there any sort of "absolute" recommendation to avoid a rewrite graph which is too long? Say "don't have more than 4 rewrites" for instance. Could (yes, but rather should) I keep invitations to join an organization inside SpiceDB? Or should I keep invitations somewhere else and when it's accepted, add a direct relation

organization:123#member@user:john

definition user {}
definition invitation {
  relation acceptor : user;
}
definition organization {
  relation invite : invitation;
}
definition org_role {
  relation invite : organization#invite;
  relation member : user;
 
  permission access = member & invite->acceptor
}
definition resource {
   relation reader: org_role#access;
}

Jake

10/29/2021, 1:18 PM

@User it's probably a good idea to store invitations, they're useful for permissions

Jake

10/29/2021, 1:19 PM

you could add a new object type for

email

Jake

10/29/2021, 1:20 PM

and then you could do check requests like:

check("org:bigco", "can_join", "email:theusersemail")

Jake

10/29/2021, 1:21 PM

you may need to encode the email as I don't believe we currently allow

symbols in object IDs

Jake

10/29/2021, 1:22 PM

i don't think you want to have access go through accepted invites though, I would remove the invite relationship when it's accepted, or just augment it with an actual

member

relationship

Jake

10/29/2021, 1:22 PM

as for the rule about performance of rewrites, there are no hard and fast rules, it's up to your use case

Jake

10/29/2021, 1:24 PM

wider rewrites, e.g.

permission access = thing + otherthing + anotherthing + afourththing

will be evaluated in parallel, whereas things that are deeply nested will need to resolve things in sequence

Sleipnir

10/29/2021, 1:28 PM

Can someone explain what the

...

relation means?

Jake

10/29/2021, 2:02 PM

@User that is something that comes from the Zanzibar paper, and we have deprecated it everywhere except the datastore layer

Jake

10/29/2021, 2:03 PM

where are you seeing it?