Permission model

• 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 included in any list query response.
    • 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.

System user and group

A privileged user account exists for the use by internal Arvados components. This user manages system objects which should not be “owned” by any particular user. The system user uuid is {siteprefix}-tpzed-000000000000000.

Anoymous user and group

An Arvado site may be configued to allow users to browse resources without requiring a log in. In this case, permissions for non-logged-in users are associated with the “anonymous” user. To make objects visible to the public, they can be shared with the “anonymous” group. The anonymous user uuid is {siteprefix}-tpzed-anonymouspublic. The anonymous group uuid is {siteprefix}-j7d0g-anonymouspublic.

Example

---

Previous: Computing with Crunch Next: Federation