Groups Projects Ownership and Permissions Specification » History » Revision 11
Revision 10 (Peter Amstutz, 08/07/2014 09:33 AM) → Revision 11/28 (Tom Clegg, 08/07/2014 09:39 AM)
h1. Groups, Projects, Ownership and Permissions Specification 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@ 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 ** *can_read* grants read-only access to the record. Attempting to update the record returns an error. ** *can_write* permits changes to content (but not metadata) fields of the record. *can_write* also implies *can_read* ** *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* h3. Questions What level of permission is required to delete an Object? h2. Ownership * All Arvados objects have an @owner_uuid@ field. Valid uuid types for @owner_uuid@ are "User" or "Group". * The User or Group specified by @owner_uuid@ has *can_manage* permission on the object. ** 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@ * In the UI, objects should be displayed as being contained within the @owner_uuid@ User or Group. ** A "Project" is a subtype of Group that indicates the group should be displayed in the "Projects" section of Workbench. h3. Questions Moving an object from Group A to Group B implies changing the @owner_uuid@ field from Group A to Group B. * What permission is required on the object itself to change the @owner_uuid@ field? → can_write * What permission is required on Group A to change the object @owner_uuid@ field so it no longer points to Group A? This logically removes the object from Group A. → can_write * What permission is required on Group Project B to set the object @owner_uuid@ field to Group B? This logically adds the object to Group B. → can_write h2. Permission links A link object with * @link_class@ "permission" * @name@ one of *can_read*, *can_write* or *can_manage* * @head_uuid@ of some Arvados object * @tail_uuid@ of an User or Group grants the @name@ permission for @tail_uuid@ accessing @head_uuid@ h3. Question * Permission links, like any other Arvados object, have a @owner_uuid@ of the user that created them, so the user retains the ability to modify the permission link. * If another user has *can_manage* on some object, does this imply the ability to modify or delete permission links where the @head_uuid@ is the object? h2. Transitive permissions * If a User *can_read* Group A, and Group A *can_read* group B, then User *can_read* Group B. * Permissions are narrowed to the least powerful permission on the path. ** If User *can_write* Group A, and Group A *can_read* Group B, then User *can_read* Group B. ** If User *can_read* Group A, and Group A *can_write* Group B, then User *can_read* 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, *can_write* and *can_manage* should be denied to all users, including administrators. * Permission links where @tail_uuid@ is a User permit @can_read@ on the link by that user. (User can discover her own permission grants.)