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 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

Questions¶

What level of permission is required to delete an Object?

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.

Questions¶

Moving an object from Group A to Group B implies changing the owner_uuid field from Group A to Group B.

• What permission is required on the object itself to change the owner_uuid field? → can_write
• What permission is required on Group A to change the object owner_uuid field so it no longer points to Group A? This logically removes the object from Group A. → can_write
• What permission is required on Group B to set the object owner_uuid field to Group B? This logically adds the object to Group B. → can_write

Permission links¶

A link object with

• 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

Question¶

• Permission links, like any other Arvados object, have a owner_uuid of the user that created them, so the user retains the ability to modify the permission link.
• If another user has can_manage on some object, does this imply the ability to modify or delete permission links where the head_uuid is the 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.)