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 a User or Group

grants the name permission for tail_uuid accessing head_uuid

• If a User has can_manage permission on some object, this grants permission to create, update and delete permission links where the head_uuid is the object under management.

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, the log table should deny all update or delete operations.
• Permission links where tail_uuid is a User permit can_read on the link by that user. (User can discover her own permission grants.)
• can_read on a Collection grants permission to read the blocks that make up the collection (API server returns signed blocks)