• Problem in access policies that causes problems in some use cases. Introducing emergency fix into 2.x branch.
    • Was originally recursive
      • mirrored postgres
      • not recursive creates policy leak
      • postgres uses recursive because you are not supposed to write complex rules
      • can still do recursive policies, but they are not recursive by default
        • recursive by default is hard to reason
      • policies are not part of schema; in DDL
        • These are made to protect data from developer. Should not be exposed to developer in schema.
    • Access policies are in schema
    • role-based policies
    • Yury: can’t see which policies are applied all the time looking at the schema
    • Elvis: mandatory role-based access control is niche, not mainstream. Most people will just care about user access. Since this is a niche feature. Modifiers seem in reference documentation and will lead to confusion. Super-advanced. You should know what you’re doing. Developers should know what you’re doing. Separate section in documentation.
    • Yury wants to get it right so we don’t have to change it again in the future.
    • Victor: With this change, can still do everything you can do now. You just don’t have to do it. Simpler layering and simpler reasoning.
    • Elvis: not applying your rules in other rules is not a security problem. Should not be able to not apply rules you don’t own.
    • Elvis: question: Do you want the rules to be mandatory? Price of security is convenience and/or performance.
    • If you don’t own the policy, the policy will be applied.
    • Roles will inherit from other roles (“top secret” would inherit from everything else). Inheritance: you have everything your parent has and something else.
    • Yury: Makes the hierarchy backwards. Lowest is at the top.
    • Elvis: We already have role inheritance. Mirrors postgres and other platforms like Github.
  • Downgrading EdgeDB
    • Sully: Downgrades only work if you upgraded.
    • Elvis: That’s fine. Trying to fix the use case where user upgraded and needs to roll back.
  • Sully: User on Discord was using introspection into annotations to decide who has access
    • Elvis built web front-end from annotations Idea for a demo project?
  • How to document access policies
    • Victor will write documentation
    • in release announcement
    • Good idea to use because it will be mandatory in 3.0
    • Yury: maybe flip feature in 2.x?
    • Elvis: new schemas have it by default by including it in the schema with edgedb project init
    • Yury: does it have to be in schema?
    • Elvis: yes