Idea #3171
closed
[API] Modify permission model to allow users to see a subset of other users, according to group permissions/membership.
Added by Tom Clegg over 10 years ago.
Updated about 10 years ago.
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
Files
- Target version set to 2014-08-06 Sprint
- 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
- Assigned To set to Tom Clegg
- Target version changed from 2014-08-06 Sprint to 2014-08-27 Sprint
- Description updated (diff)
- Status changed from New to In Progress
- File Screenshot from 2014-08-24 23_59_08.png added
- File deleted (
Screenshot from 2014-08-24 23_59_08.png)
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).
- Status changed from In Progress to Resolved
Applied in changeset arvados|commit:437725d13f8775b29ad3e279a07b0bd4b7f8d098.
Also available in: Atom
PDF