Project

General

Profile

Actions

Groups Projects Ownership and Permissions Specification » History » Revision 20

« Previous | Revision 20/28 (diff) | Next »
Peter Amstutz, 08/25/2014 09:53 AM


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, 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.)
  • can_read on a Collection grants permission to read the blocks that make up the collection (API server returns signed blocks)

Updated by Peter Amstutz over 9 years ago · 20 revisions