Project

General

Profile

Groups Projects Ownership and Permissions Specification » History » Revision 24

Revision 23 (Peter Amstutz, 08/25/2014 11:31 AM) → Revision 24/28 (Tom Clegg, 08/26/2014 07:29 PM)

h1. Groups, Projects, Ownership and Permissions Specification 

 

 h2. Permissions 

 * There are four levels of permission: permission, *none*, *can_read*, *can_write*, and *can_manage*. 
 ** *none* is the default state when there are no other permission grants. grants 
 *** the object is not returned by any list query. query 
 *** direct queries of the object by uuid return 404 Not Found. 
 *** Link objects require valid identifiers in @head_uuid@ and 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. 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 grant the ability to see any permission grants on the object except the object's owner_uuid ownership and the reader's user's own permissions. 
 ** *can_write* permits changes to the record content (but not permission links). metadata links, such as permissions) fields of the record.    *can_write* permits the user to delete the object.    *can_write* also implies *can_read*. *can_read* 
 ** *can_manage* permits the user to read, create, update and delete permission links whose with @head_uuid@ is set to this object's @uuid@. object.    *can_manage* also implies *can_write* and *can_read*. 

 *can_read* 

 h2. Ownership 

 * All Arvados objects have an @owner_uuid@ field.    Valid uuid types for @owner_uuid@ are "User" and or "Group". 
 * The User or Group specified by @owner_uuid@ has *can_manage* permission on the object. 
 ** This permission is one way: A way; if the owned object is also a User or Group's @owner_uuid@ being equal to @X@ Group, this does not imply confer any permission for that User/Group to read, write, the User or manage an object whose @uuid@ is equal Group to @X@. access its @owner_uuid@ 
 * Applications In the UI, objects should represent each object be displayed as belonging to, or being "inside", contained within the Group/User referenced by its @owner_uuid@. @owner_uuid@ User or Group. 
 ** 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 indicates the group should be displayed in Workbench as a group the "Projects" section of users who have permissions in common (typically an organizational group). Workbench. 
 * To change the @owner_uuid@ field, it is necessary to the User must 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. 


 


 h2. Transitive permissions 

 Permissions can be obtained indirectly through Groups. 
 * If a User X *can_read* Group A, and Group A *can_read* Object group B, then User X *can_read* Object Group 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 Group B, then User X *can_read* Object Group B. 
 ** If User X *can_read* Group A, and Group A *can_write* Object Group B, then User X *can_read* Object Group B. 

 

 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_.