Story #3171

[API] Modify permission model to allow users to see a subset of other users, according to group permissions/membership.

Added by Tom Clegg over 5 years ago. Updated about 5 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
API
Target version:
Start date:
08/20/2014
Due date:
% Done:

100%

Estimated time:
(Total: 15.00 h)
Story points:
2.0

Description

Currently, we have

Permission links Behavior
No permission path from userA to userB userA can see selected attributes of userB via users#index (as needed by the Sharing tab).
{userA} can_read {groupG} can_read {userB} userA can read anything userB can read.

This should change to

Permission links Behavior
No permission path from userA to userB userA cannot see that userB exists.
userB's uuid might appear in objects, but
GET /users/userB will yield 404
GET /users will not mention userB)
{userA} can_read {groupG} can_read {userB} userA can see selected attributes of userB via users#index (as needed by the Sharing tab).
{userA} can_read {groupG} can_manage {userB} userA can read anything userB can read.

Implementation

  • When generating the permissions graph in user.rb, follow only the permission links whose head_uuid is a group uuid or whose permission name is "can_manage".
  • The test cases involving "rominiadmin" might still work unmodified: the testusergroup_can_manage_active_user link has can_manage permission.
  • Add test cases to demonstrate the new behavior, perhaps
    • new link: testusergroup can_read spectator
    • test: miniadmin user cannot read the owned_by_spectator specimen
    • test: miniadmin user can get the spectator user record via index and get
    • test: active user cannot get the spectator user record

Subtasks

Task #3563: Write testsResolvedTom Clegg

Task #3562: Change permission modelResolvedTom Clegg

Task #3653: Review 3171-group-membershipResolvedTom Clegg

Task #3564: Design appropriate "join group" interfaceResolvedTom Clegg

Task #3565: Implement admin "add user to group" and "create/rename groups" interfaceResolvedTom Clegg

Task #3665: Review 3171-admin-groupsResolvedPeter Amstutz

Associated revisions

Revision da34478c
Added by Tom Clegg about 5 years ago

Merge branch '3171-group-membership' refs #3171

Revision 437725d1
Added by Tom Clegg about 5 years ago

Merge branch '3171-admin-groups' closes #3171

Revision 015be614 (diff)
Added by Tom Clegg about 5 years ago

Fix test fixtures breaking Workbench tests. refs #3171

History

#1 Updated by Tom Clegg over 5 years ago

  • Target version set to 2014-08-06 Sprint

#2 Updated by Radhika Chippada over 5 years ago

  • Subject changed from Modify permission model to allow users to see a subset of other users, according to group permissions/membership. to [API] Modify permission model to allow users to see a subset of other users, according to group permissions/membership.
  • Category set to API

#3 Updated by Tom Clegg over 5 years ago

  • Assigned To set to Tom Clegg

#4 Updated by Tom Clegg about 5 years ago

  • Target version changed from 2014-08-06 Sprint to 2014-08-27 Sprint

#5 Updated by Tom Clegg about 5 years ago

  • Description updated (diff)

#6 Updated by Tom Clegg about 5 years ago

  • Status changed from New to In Progress

#7 Updated by Tom Clegg about 5 years ago

  • File Screenshot from 2014-08-24 23_59_08.png added

#8 Updated by Tom Clegg about 5 years ago

  • File deleted (Screenshot from 2014-08-24 23_59_08.png)

#10 Updated by Peter Amstutz about 5 years ago

This is exactly why I wrote https://arvados.org/projects/arvados/wiki/Groups_Projects_Ownership_and_Permissions_Specification

  • The model doesn't say what a group having can_write on a user means.
  • I'm concerned about overloading can_manage permission. There doesn't seem to be a way to give a group can_read on your account without also giving anyone with can_manage on the group can_manage access to your user account.
  • This breaks the principal "permissions are narrowed to the least powerful permission on the path" because both can_read -> can_read and can_read -> can_manage both yield can_read, but in this case it actually yields two different kinds of can_read.

I suggest that we introduce a new permission link_class that is weaker than can_read (can_view?) which grants read access to an individual record but doesn't grant transitive permissions. Then we can properly define can_read to include various kinds of transitive permission, such as being able to read everything a user can read, or be able to read a job's log and output, etc.

(alternately we redefine can_read down, and introduce a new transitive_read permission).

#12 Updated by Anonymous about 5 years ago

  • Status changed from In Progress to Resolved

Applied in changeset arvados|commit:437725d13f8775b29ad3e279a07b0bd4b7f8d098.

Also available in: Atom PDF