Project

General

Profile

Actions

Groups, Projects, Ownership and Permissions Specification

See also: http://doc.arvados.org/api/permission-model.html

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 and 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 or delete the record returns an error. can_read does not allow a reader to see any permission grants on the object except the object's owner_uuid and the reader's own permissions.
    • can_write permits changes to the record (but not permission links). can_write permits the user to delete the object. can_write also implies can_read.
    • can_manage permits the user to read, create, update and delete permission links whose head_uuid is this object's uuid. 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" and "Group".
  • The User or Group specified by owner_uuid has can_manage permission on the object.
    • This permission is one way: A User or Group's owner_uuid being equal to X does not imply any permission for that User/Group to read, write, or manage an object whose uuid is equal to X.
  • Applications should represent each object as belonging to, or being "inside", the Group/User referenced by its owner_uuid.
    • A "project" is a subtype of Group that is treated as a "Project" in Workbench, and as a directory by arv-mount.
    • A "role" is a subtype of Group that is treated in Workbench as a group of users who have permissions in common (typically an organizational group).
  • To change the owner_uuid field, it is necessary to 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 read, create, update and delete permission links where the head_uuid is the object under management.

Transitive permissions

Permissions can be obtained indirectly through Groups.
  • If a User X can_read Group A, and Group A can_read Object B, then User X can_read Object B.
  • Permissions are narrowed to the least powerful permission on the path.
    • If User X can_write Group A, and Group A can_read Object B, then User X can_read Object B.
    • If User X can_read Group A, and Group A can_write Object B, then User X can_read Object B.

Group Membership

Group membership is determined by whether the group has can_read permission on an object. If a group G can_read an object A, then we say A is a member of G.

For some kinds of groups, like roles, it is natural for users who are members of a group to also have can_manage permission on the group, i.e., G can_read A and A can_manage G ("A can do anything G can do"). However, this is not necessary: A can be a member of a group while being unable to even read it.

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)
  • If User or Group X can_FOO Group A, and Group A can_manage User B, then X can_FOO everything that User B can_FOO.

Updated by Tom Clegg over 9 years ago · 28 revisions