Project

General

Profile

Groups Projects Ownership and Permissions Specification » History » Version 21

Peter Amstutz, 08/25/2014 09:54 AM

1 1 Peter Amstutz
h1. Groups, Projects, Ownership and Permissions Specification
2
3 3 Peter Amstutz
h2. Permissions
4
5 6 Peter Amstutz
* There are four levels of permission, *none*, *can_read*, *can_write*, and *can_manage*.
6 9 Peter Amstutz
** *none* is the default state when there are no other permission grants
7
*** the object is not returned by any list query
8
*** direct queries of the object by uuid return 404 Not Found.
9 6 Peter Amstutz
*** Link objects require valid identifiers in @head_uuid@ or @tail_uuid@, so an attempt to create a Link that references an unreadable object will return an error indicating the object is not found
10
** *can_read* grants read-only access to the record.  Attempting to update the record returns an error.
11 15 Peter Amstutz
** *can_write* permits changes to content (but not metadata) fields of the record.  *can_write* permits the user to delete the object.  *can_write* also implies *can_read*
12 1 Peter Amstutz
** *can_manage* permits the user to create permission links with @head_uuid@ set to this object.  *can_manage* also implies *can_write* and *can_read*
13 4 Peter Amstutz
14 1 Peter Amstutz
h2. Ownership
15 3 Peter Amstutz
16 1 Peter Amstutz
* All Arvados objects have an @owner_uuid@ field.  Valid uuid types for @owner_uuid@ are "User" or "Group".
17 9 Peter Amstutz
* The User or Group specified by @owner_uuid@ has *can_manage* permission on the object.
18
** This permission is one way; if the owned object is also a User or Group, this does not confer any permission for the User or Group to access its @owner_uuid@
19
* In the UI, objects should be displayed as being contained within the @owner_uuid@ User or Group.
20
** A "Project" is a subtype of Group that indicates the group should be displayed in the "Projects" section of Workbench.
21 14 Peter Amstutz
* To change the @owner_uuid@ field, the User must have @can_write@ permission on both the current owner and the new owner.
22 1 Peter Amstutz
23 5 Peter Amstutz
h2. Permission links
24 1 Peter Amstutz
25 3 Peter Amstutz
A link object with
26 4 Peter Amstutz
27 15 Peter Amstutz
* @owner_uuid@ of the system user.
28 4 Peter Amstutz
* @link_class@ "permission"
29
* @name@ one of *can_read*, *can_write* or *can_manage*
30 1 Peter Amstutz
* @head_uuid@ of some Arvados object
31 19 Peter Amstutz
* @tail_uuid@ of a User or Group
32 4 Peter Amstutz
33 7 Peter Amstutz
grants the @name@ permission for @tail_uuid@ accessing @head_uuid@
34 13 Tom Clegg
35 20 Peter Amstutz
* If a User has *can_manage* permission on some object, this grants permission to create, update and delete permission links where the @head_uuid@ is the object under management.
36 16 Peter Amstutz
37 1 Peter Amstutz
h2. Transitive permissions
38 3 Peter Amstutz
39
* If a User *can_read* Group A, and Group A *can_read* group B, then User *can_read* Group B.
40 4 Peter Amstutz
* Permissions are narrowed to the least powerful permission on the path.
41 3 Peter Amstutz
** If User *can_write* Group A, and Group A *can_read* Group B, then User *can_read* Group B.
42 1 Peter Amstutz
** If User *can_read* Group A, and Group A *can_write* Group B, then User *can_read* Group B.
43 10 Peter Amstutz
44
h2. Special cases
45
46 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.
47 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.)
48 18 Peter Amstutz
* *can_read* on a Collection grants permission to read the blocks that make up the collection (API server returns signed blocks)