Idea #3171
closed
[API] Modify permission model to allow users to see a subset of other users, according to group permissions/membership.
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, butGET /users/userB will yield 404GET /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
nameis"can_manage". - The test cases involving "rominiadmin" might still work unmodified: the
testusergroup_can_manage_active_userlink hascan_managepermission. - 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
Files
Updated by Tom Clegg almost 10 years ago
- Target version set to 2014-08-06 Sprint
Updated by Radhika Chippada almost 10 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
Updated by Tom Clegg over 9 years ago
- Target version changed from 2014-08-06 Sprint to 2014-08-27 Sprint
Updated by Tom Clegg over 9 years ago
- File Screenshot from 2014-08-24 23_59_08.png added
Updated by Tom Clegg over 9 years ago
- File deleted (
Screenshot from 2014-08-24 23_59_08.png)
Updated by Tom Clegg over 9 years ago
Updated by Peter Amstutz over 9 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).
Updated by Tom Clegg over 9 years ago
(I should update http://doc.arvados.org/api/permission-model.html)
Updated by Anonymous over 9 years ago
- Status changed from In Progress to Resolved
Applied in changeset arvados|commit:437725d13f8775b29ad3e279a07b0bd4b7f8d098.