doc/api/permission-model.html.textile.liquid

   1 ---
   2 layout: default
   3 navsection: architecture
   4 navmenu: Concepts
   5 title: "Permission model"
   6 ...
   7 {% comment %}
   8 Copyright (C) The Arvados Authors. All rights reserved.
   9
  10 SPDX-License-Identifier: CC-BY-SA-3.0
  11 {% endcomment %}
  12
  13 * There are four levels of permission: *none*, *can_read*, *can_write*, and *can_manage*.
  14 ** *none* is the default state when there are no other permission grants.
  15 *** the object is not included in any list query response.
  16 *** direct queries of the object by uuid return 404 Not Found.
  17 *** 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.
  18 ** *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.
  19 ** *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*.
  20 ** *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*.
  21
  22 h2. Ownership
  23
  24 * All Arvados objects have an @owner_uuid@ field. Valid uuid types for @owner_uuid@ are "User" and "Group".
  25 * The User or Group specified by @owner_uuid@ has *can_manage* permission on the object.
  26 ** 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@.
  27 * Applications should represent each object as belonging to, or being "inside", the Group/User referenced by its @owner_uuid@.
  28 ** A "project" is a subtype of Group that is treated as a "Project" in Workbench, and as a directory by @arv-mount@.
  29 ** 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).
  30 * To change the @owner_uuid@ field, it is necessary to have @can_write@ permission on both the current owner and the new owner.
  31
  32 h2(#links). Permission links
  33
  34 A link object with
  35
  36 * @owner_uuid@ of the system user.
  37 * @link_class@ "permission"
  38 * @name@ one of *can_read*, *can_write* or *can_manage*
  39 * @head_uuid@ of some Arvados object
  40 * @tail_uuid@ of a User or Group
  41
  42 grants the @name@ permission for @tail_uuid@ accessing @head_uuid@
  43
  44 * 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.
  45
  46 h3. Transitive permissions
  47
  48 Permissions can be obtained indirectly through Groups.
  49 * If a User X *can_read* Group A, and Group A *can_read* Object B, then User X *can_read* Object B.
  50 * Permissions are narrowed to the least powerful permission on the path.
  51 ** If User X *can_write* Group A, and Group A *can_read* Object B, then User X *can_read* Object B.
  52 ** If User X *can_read* Group A, and Group A *can_write* Object B, then User X *can_read* Object B.
  53
  54 h2. Group Membership
  55
  56 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.
  57
  58 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.
  59
  60 h2. Special cases
  61
  62 * 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.
  63 * Permission links where @tail_uuid@ is a User permit @can_read@ on the link by that user.  (User can discover her own permission grants.)
  64 * *can_read* on a Collection grants permission to read the blocks that make up the collection (API server returns signed blocks)
  65 * 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_.
  66
  67 h2(#system). System user and group
  68
  69 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@.
  70
  71 h2. Anoymous user and group
  72
  73 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@.
  74
  75 h2. Example
  76
  77 !(full-width){{site.baseurl}}/images/Arvados_Permissions.svg!