Project

General

Profile

Groups Projects Ownership and Permissions Specification » History » Version 28

Tom Clegg, 10/03/2014 08:39 PM

1 1 Peter Amstutz
h1. Groups, Projects, Ownership and Permissions Specification
2
3 25 Tom Clegg
See also: http://doc.arvados.org/api/permission-model.html
4
5
{{toc}}
6
7 3 Peter Amstutz
h2. Permissions
8
9 24 Tom Clegg
* There are four levels of permission: *none*, *can_read*, *can_write*, and *can_manage*.
10
** *none* is the default state when there are no other permission grants.
11
*** the object is not returned by any list query.
12 9 Peter Amstutz
*** direct queries of the object by uuid return 404 Not Found.
13 24 Tom Clegg
*** 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.
14
** *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.
15
** *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*.
16
** *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*.
17 23 Peter Amstutz
18 4 Peter Amstutz
h2. Ownership
19 1 Peter Amstutz
20 24 Tom Clegg
* All Arvados objects have an @owner_uuid@ field. Valid uuid types for @owner_uuid@ are "User" and "Group".
21 1 Peter Amstutz
* The User or Group specified by @owner_uuid@ has *can_manage* permission on the object.
22 24 Tom Clegg
** 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@.
23
* Applications should represent each object as belonging to, or being "inside", the Group/User referenced by its @owner_uuid@.
24
** A "project" is a subtype of Group that is treated as a "Project" in Workbench, and as a directory by @arv-mount@.
25
** 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).
26
* To change the @owner_uuid@ field, it is necessary to have @can_write@ permission on both the current owner and the new owner.
27 1 Peter Amstutz
28 5 Peter Amstutz
h2. Permission links
29 1 Peter Amstutz
30 3 Peter Amstutz
A link object with
31 4 Peter Amstutz
32 1 Peter Amstutz
* @owner_uuid@ of the system user.
33
* @link_class@ "permission"
34
* @name@ one of *can_read*, *can_write* or *can_manage*
35
* @head_uuid@ of some Arvados object
36 19 Peter Amstutz
* @tail_uuid@ of a User or Group
37 4 Peter Amstutz
38 7 Peter Amstutz
grants the @name@ permission for @tail_uuid@ accessing @head_uuid@
39 13 Tom Clegg
40 22 Peter Amstutz
* 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.
41 1 Peter Amstutz
42 26 Tim Pierce
h3. Transitive permissions
43 1 Peter Amstutz
44 24 Tom Clegg
Permissions can be obtained indirectly through Groups.
45
* If a User X *can_read* Group A, and Group A *can_read* Object B, then User X *can_read* Object B.
46 4 Peter Amstutz
* Permissions are narrowed to the least powerful permission on the path.
47 1 Peter Amstutz
** If User X *can_write* Group A, and Group A *can_read* Object B, then User X *can_read* Object B.
48
** If User X *can_read* Group A, and Group A *can_write* Object B, then User X *can_read* Object B.
49 26 Tim Pierce
50
h2. Group Membership
51
52 27 Tom Clegg
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.
53 1 Peter Amstutz
54 28 Tom Clegg
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.
55 10 Peter Amstutz
56
h2. Special cases
57
58 21 Peter Amstutz
* 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.
59 10 Peter Amstutz
* Permission links where @tail_uuid@ is a User permit @can_read@ on the link by that user.  (User can discover her own permission grants.)
60 18 Peter Amstutz
* *can_read* on a Collection grants permission to read the blocks that make up the collection (API server returns signed blocks)
61 24 Tom Clegg
* 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_.