Arvados

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* permits the user to delete the object.  *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*

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.

* To change the @owner_uuid@ field, 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* on some object, this grants the permission to update the @name@ field, or delete the link, for links where the @head_uuid@ is the object.

h3. Proposal (not finalized)

* *can_read*, *can_write*, and *can_manage* require that both @head_uuid@ and @tail_uuid@ are User or Group.

* *can_login* requires @tail_uuid@ is a User (not a Group) and @head_uuid@ is a VM.  Also grants *can_read* on the VM object.

* *can_fetch* and *can_push* requires @head_uuid@ is a repository.  Also grants *can_read* on the repository 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.)

* *can_read* on a Collection grants permission to read the blocks that make up the collection (API server returns signed blocks)