Groups, Projects, Ownership and Permissions Specification¶

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

• Table of contents
• Groups, Projects, Ownership and Permissions Specification
  • Permissions
  • Ownership
  • Permission links
    • Transitive permissions
  • Group Membership
  • Special cases

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.