Permission and workspace overhaul

[dsonck92]

Currently, the permission system is functional, but has some rough edges.

Current situation

Permissions

• Nodes

  • Each node has associated permissions for that given node
  • Each node also has an associated ownership

• Access

  • Ownership gives all rights
  • Associated permissions can give different levels:
    • viewer
    • editor
    • owner

• Actions

  • Sharing a node does the following:
    • the desired permissions for that given node are added
    • the desired permissions are also applied to all nodes underneath the shared node
    • view access is given to the path leading up to the node
  • Creating a new node makes the creator owner, and does not alter further permissions
  • Moving nodes does not alter any permissions and only alters the parent link
  • Copying nodes duplicates the node and only gives ownership (as with creation)

Workspaces

• A workspace has an association with the tree through its root_id
• Every node also has an reverse association through its workspace_id
• A workspace has an association with a bucket

Organizations

• Contains users
• Contains groups
• Contains workspaces

Proposed new situation

• Permissions
  • True ownership will be removed (aka, owner_id)
  • viewer can view nodes, and give others max viewer permissions
  • editor can do above and create, move and copy nodes and give others max editor permissions
  • owner can do above and delete and give others owner permissions
  • permissions are given on a numerical value, where higher means more power and 0 is nothing
• Voltaserve will use a configurable bucket per organization to store data under with configurable credentials
• Voltaserve can optionally read "bucket creation" credentials to automate bucket management
• The filesystem consists of hierarchical nodes with parent_id indicating child relations
• Filesystem nodes do not have associated permissions or ownership
• Workspaces point to nodes in the filesystem through its root_id
• A filesystem node needs at least a non-null parent_id or an associated root_id from a workspace
• Workspaces carry permissions of their subtree and must have at least one owner level access grant
• Multiple workspaces can be associated to a given node
  • permission will be the union of all workspaces
  • max of all permission levels for a user is the level in effect: membership of viewer and editor makes editor
• A workspace mounted underneath a tree will override the permissions inherited from above
• Organizations are considered "tenants" and
  • Are selected "globally" in Voltaserve, instead of from a side view, and directly affect what groups/workspaces are seen
  • Can be assigned to a domain to allow customers of a managed voltaserve to bring their own domain name
  • Has a configurable bucket assignment

Motivations for decisions

• Filesystem focusing on hierarchy allows a regular filesystem like system
• No filesystem local permissions allow quick filesystem operations regarding move/copy/delete by acting on the nodes
• Workspaces acting as pointers allows exposing the abstract tree of files to logical entry points.
• Making workspaces the leading source of permissions keeps the permission system centralized:
  • Organizations carry the global user associations
  • Workspaces carry the sharing between users or public links
  • Inheritance is easier to reason about as we know that we just need to seek the nearest workspace to calculate the permissions. Associated with files (inherited or not) requires careful consideration how new permissions are flowing
• Multiple workspace associations allows different users to see the tree as they seem fit and has a flexible permission system:
  • Each workspace defines a very narrow scope of how to share: I share this folder as a working space "OC product" with person Bob, and also as "Wolfgirl drawing" with Alice. Alice and Bob don't know they see the same result.
  • This also allows granting a subset of directories with a clear chain with other people. Expanding: "Alice can get her own drafts subspace underneath the OC product/Wolfgirl drawing that Bob totally doesn't know exists.
• Removing the concept of an owner from the entity...
  • makes access calculations a simple "does permission where owner_id and resource_id exist", instead of also checking the entity itself
  • allows closing the "creator" account without the node going away, at least if 1 owner still exists
• Utilizing numerical permission "levels" allows easier calculation by "max" or "min". In go this can be an iota const enum.
• Utilizing one bucket per org makes it easier for voltaserve to utilize existing infrastructure (self hosted or AWS S3) and...
  • AWS is less optimized for bucket actions, and more optimized on bucket contents modification
  • AWS has a default limit of 100 buckets, orgs are meant not to be as many as workspaces
  • configurable settings allows reuse of buckets, or external administration of buckets

Suggested implementation

• Workspace has id, organisation_id, owner_id and root_id
• Join table of user <-> workspace indicating permissions
• nodes have parent_id; workspace_id is removed
• permission check seeks out nearest workspace and unions the result, taking the max permission of all associated permissions.

[dsonck92]