Groups, Projects, Ownership and Permissions Specification¶

Permissions¶

• There are four levels of permission, none, can_read, can_write, and can_manage.
  • none is the default state when there are no other permission grants
    • the object is not returned by any list query
    • direct queries of the object by uuid return 404 Not Found.
    • Link objects require valid identifiers in head_uuid or tail_uuid, so an attempt to create a Link that references an unreadable object will return an error indicating the object is not found
  • can_read grants read-only access to the record. Attempting to update the record returns an error.
  • can_write permits changes to content (but not metadata) fields of the record. can_write permits the user to delete the object. can_write also implies can_read
  • can_manage permits the user to create permission links with head_uuid set to this object. can_manage also implies can_write and can_read

Ownership¶

• All Arvados objects have an owner_uuid field. Valid uuid types for owner_uuid are "User" or "Group".
• The User or Group specified by owner_uuid has can_manage permission on the object.
  • This permission is one way; if the owned object is also a User or Group, this does not confer any permission for the User or Group to access its owner_uuid
• In the UI, objects should be displayed as being contained within the owner_uuid User or Group.
  • A "Project" is a subtype of Group that indicates the group should be displayed in the "Projects" section of Workbench.
• To change the owner_uuid field, the User must have can_write permission on both the current owner and the new owner.

Permission links¶

A link object with

• owner_uuid of the system user.
• link_class "permission"
• name one of can_read, can_write or can_manage
• head_uuid of some Arvados object
• tail_uuid of an User or Group

grants the name permission for tail_uuid accessing head_uuid

• If a User has can_manage on some object, this grants the permission to update the name field, or delete the link, for links where the head_uuid is the object.

Proposal (not finalized)¶

• can_read*, can_write, and can_manage require that both head_uuid and tail_uuid are User or Group.
• can_login requires tail_uuid is a User (not a Group) and head_uuid is a VM. Also grants can_read on the VM object.
• can_fetch and can_push requires head_uuid is a repository. Also grants can_read on the repository object.

Transitive permissions¶

• If a User can_read Group A, and Group A can_read group B, then User can_read Group B.
• Permissions are narrowed to the least powerful permission on the path.
  • If User can_write Group A, and Group A can_read Group B, then User can_read Group B.
  • If User can_read Group A, and Group A can_write Group B, then User can_read Group B.

Special cases¶

• Log table objects are additionally readable based on whether the User has can_read permission on object_uuid (User can access log history about objects it can read). To retain the integrity of the log, can_write and can_manage should be denied to all users, including administrators.
• Permission links where tail_uuid is a User permit can_read on the link by that user. (User can discover her own permission grants.)