Groups Projects Ownership and Permissions Specification » History » Revision 27
Revision 26 (Tim Pierce, 10/03/2014 08:14 PM) → Revision 27/28 (Tom Clegg, 10/03/2014 08:32 PM)
h1. Groups, Projects, Ownership and Permissions Specification
See also: http://doc.arvados.org/api/permission-model.html
{{toc}}
h2. 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*.
h2. 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.
h2. 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.
h3. 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.
h2. 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 the group G.
For some kinds Most of groups, the time, it is natural will be important for users who are members of a group to also have *can_read* read permission on the group, i.e., i.e. A *can_read* G and G *can_read* A. However, this It is not necessary: possible for A can to be a member of a the group while being but be unable to read it; if that is the case, A will not be able to view the group or any of the other members in it.
h2. 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_.