Arvados

I suspect this is working as designed.

It depends on the access that the user has to the group.

If the user has "write" access to the group, that means the user only gets "write" access to things that the group can "write" or "manage".

If the user has "manage" access to the group, then the user also gets "manage" access to things the group can manage.

If the user has "manage" access to the group, and the groups gets "write" access, then the user only gets "write" access.

As a feature, we may be missing a permission level where a user is able to manage things the group can manage, but not manage the group itself.

I think the expected behavior depends on what you mean by a user being a member of a group, which isn't quite clear in the description.

In this case the user should see sharing controls for the project. This is what Workbench1 does when you use the "add user to group" admin feature.

       can_manage            can_manage
user --------------> group --------------> project

In this case the user should not see sharing controls for the project. This might happen if something other than the Workbench1 admin page is used to add the user→group permission link.

       can_write             can_manage
user --------------> group --------------> project

Permissions are narrowed to the least powerful permission on the path.

If I'm understanding it correctly, the current model seems wrong to me. I expect the rights to manage a group to be orthogonal to the rights that membership in a group grants me. The rights that I have to an object should be the union of my individual rights plus the rights of all groups of which I'm a member. Granting a group member manage access to the group itself, just so that they're able to exercise their right to manage objects shared with the group, allows them to change membership of the group, which seems highly undesirable.

Permissions should be based on group membership, not access to the group.

Proposal:

Permission links separately express "access to record immediate" and "transitive access through record"

Access levels¶

0 - None
1 - View ("metadata only", for collections this means manifest does not have permission signatures)
2 - Read
3 - Write
4 - Manage

Viewer: "View_None"

User can see the group record (name, description) but not gain any access through the group. "View" access does not grant access to the link records that point to the group, so the client cannot access the user list.

Viewer+: "Read_None"

"Read" access to a record also confers permission to query links that point to the record. This allows the client to get the list of permission links that grant access to this group. (This would allow the client to get a list of user uuids but not actually grant access to the user records, this might be fine if the user has access to the "All Users" group).

Administrator: "Manage_Manage"

"Manage" grants the ability to edit the record, and also create/update permission links that target the record. Grants at most "manage" permission to anything accessible through the group.

Member: "Read_Manage"

"Read" grants ability to read the record, and see permission links pointing to the record. Grants at most "manage" permission to anything accessible through the group.

Traversing the graph¶

Normal member¶

Membership is defined as having any permission link with tail_uuid of the user and head_uuid of the group.

start at user A

has "Read_Manage" for group B

group B has "Read_Read" for project C

project C owns collection D (this is Manage_Manage)

1. Traverse A->B, current[traversal] = Manage
   1. Compute min(current[traversal], A->B[record access]) = min(Manage, Read) = Read, access level for B is 'Read'
   2. Compute min(current[traversal], A->B[traversal]) = min(Manage, Manage) and update current[traversal] = Manage
2. Traverse B->C, current[traversal] = Manage
   1. Compute min(current[traversal], B->C[record access]) = min(Manage, Read) = Read, access level for C is 'Read'
   2. Compute min(current[traversal], B->C[traversal]) = min(Manage, Read) and update current[traversal] = Read
3. Traverse C->D, current[traversal] = Read
   1. Compute min(current[traversal], C->D[record access]) = min(Read, Manage) = Read, access level for D is 'Read'
   2. Compute min(current[traversal], B->C[traversal]) = min(Read, Manage) and update current[traversal] = Read

Group admin¶

has "Manage_Manage" for group B

1. Traverse A->B, current[traversal] = Manage
   1. Compute min(current[traversal], A->B[record access]) = min(Manage, Manage) = Read, access level for B is 'Manage'
   2. Compute min(current[traversal], A->B[traversal]) = min(Manage, Manage) and update current[traversal] = Manage

Migration¶

• can_manage turns into Manage_Manage
• can_write turns into Write_Write when head_uuid is a project and Read_Manage when head_uuid is a user group
• can_read turns into Read_Read unless head_uuid is a user, then it is "View_None"

Could add a special case "if group is readable, and permission link exists group->user, then 'user' is viewable"

Might be worth considering how our permission system might interact with the GA4GH Data Use Ontology

https://www.ga4gh.org/news/data-use-ontology-approved-as-a-ga4gh-technical-standard/

• A "role" group's UUID cannot be used as an owner_uuid (IOW a non-project group can't have children)
• A "project" group's UUID cannot be used as the tail_uuid of a permission link
• A user UUID can be a target of a can_use_permission link -- this allows access to all of the user's permissions and home project tree
• A group cannot have a group_class other than "role" or "project" (and group_class cannot be null)
• A group can have a can_use_permissions link to another group; this graph is (still) traversed, so groups can be composed
• A can_list_members link permits its subject (tail_uuid) to read all can_use_permissions links from other users/groups to the same head_uuid, as well as the member users/groups themselves
• can_manage implies can_list_members

• Obviously, update the materialized view of permissions and the "readable_by" query
• Clients that (might) need to be updated: Workbench1, Workbench2, group-sync, login-sync, arv-mount (probably drop Workbench1's group admin feature entirely rather than update it)
• Existing "Administrator" permissions convert to "Member+"
• Existing group→user links (e.g., "all users" links) convert to "Member"
• Existing project-sharing links (including read-only sharing, and sharing with role groups) can be left alone
• Warn/error if a non-project group is used as any object's owner_uuid, or a project group is used as a permission link's tail_uuid
• Update use of "all users" links in user activation code