Project

General

Profile

Actions

Feature #19269

closed

"All users" group membership should be RW, not RO

Added by Tom Clegg over 1 year ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
-
Target version:
Story points:
-
Release relationship:
Auto

Description

This will make it easy to make a project or collection world-writable. (Currently, one would need to create a role group and add everyone to it, including all future new users.)

IIRC (TC) the reason why the user→"all users" group link is read-only (can_read) is to prevent users from modifying/renaming the role group record itself. If that's the only reason, it seems like we could prevent that with a special case in the update permission check: non-admin user cannot update the well-known "all users" group.


Subtasks 1 (0 open1 closed)

Task #19288: Review 19269-all-users-writableResolvedTom Clegg08/25/2022Actions
Actions #1

Updated by Tom Clegg over 1 year ago

Also: updating the name/description/etc of a role group should require can_manage (or admin), not just can_write.

Actions #2

Updated by Peter Amstutz over 1 year ago

  • Target version set to 2022-08-03 Sprint
Actions #3

Updated by Tom Clegg over 1 year ago

  • Assigned To set to Tom Clegg
Actions #4

Updated by Tom Clegg over 1 year ago

  • Status changed from New to In Progress
Actions #5

Updated by Tom Clegg over 1 year ago

Branch in progress: 19269-group-permissions @ 68a98cf559d6743bf4d0e829932951cf26c87fff -- developer-run-tests: #3251

  • role groups can only be modified by admins, regardless of any permission links (note we were already ensuring role groups are owned by system user)
  • users#setup uses can_manage for the user->all_users_group permission link
  • migration upgrades existing user->all_users_group permission links from can_read to can_manage

This makes "share read/write with All Users" work as expected.

However, it does create a different oddity: a non-admin user can create a role (as before), but then cannot modify or delete it.

We could address this by preventing non-admin users from creating new role groups.

We should add a release note to alert admins that existing "shared at write/manage level with all users" permissions, which previously granted only read-only permission, will start grant write/manage permission after upgrading.

Actions #6

Updated by Tom Clegg over 1 year ago

"updating the name/description/etc of a role group should require can_manage (or admin), not just can_write"

Assuming we don't make a bigger change to the permission system, like introducing a "can_access_via" permission type, I think we have these options:

1. updating role requires can_manage

(1a) "add user to group" uses a can_manage link (unchanged)

Members of a role can change the role's name/description

(1b) we change membership to use a can_write link

Members of a role cannot change the role's name/description -- but "share with role X at manage level" doesn't work any more (shares are automatically restricted to can_write level)

2. updating role requires admin

(2a) Non-admin users can create role groups (unchanged)

It's weird that a non-admin user can create a new role group, but can't modify or delete it.

(2b) Only admins can create role groups

It's inconvenient that everything to do with role groups (create/modify/delete) must be done by an admin user.

Actions #7

Updated by Peter Amstutz over 1 year ago

  • Target version changed from 2022-08-03 Sprint to 2022-08-17 sprint
Actions #8

Updated by Peter Amstutz over 1 year ago

From discussion, we decided option (1) is least surprising.

Actions #9

Updated by Tom Clegg over 1 year ago

specifically (1b)

Actions #10

Updated by Peter Amstutz over 1 year ago

  • Target version changed from 2022-08-17 sprint to 2022-08-31 sprint
Actions #11

Updated by Tom Clegg over 1 year ago

updating role requires can_manage

...was done in #16007

Actions #12

Updated by Tom Clegg over 1 year ago

19269-all-users-writable @ e4c83a3ebe3b16c16f604b3b0968ce5600b7ab64 -- developer-run-tests: #3272

Changes the automatic "all users" role permissions (existing ones and new ones added by "user setup") from can_read to can_write.

Actions #13

Updated by Lucas Di Pentima over 1 year ago

Code LGTM, thanks.

One thing that I was looking for is see if we need to update some documentation, I'm not sure if we explain the special case of role groups somewhere.

Actions #14

Updated by Tom Clegg over 1 year ago

Indeed, I couldn't find any mention of that. Added in the "special cases" section of Architecture > Permission Model.

Actions #15

Updated by Tom Clegg over 1 year ago

  • % Done changed from 0 to 100
  • Status changed from In Progress to Resolved

Applied in changeset arvados-private:commit:arvados|ee5443faad325b16047b9ad4cd588baf51e231fa.

Actions #16

Updated by Peter Amstutz over 1 year ago

  • Release set to 47
Actions

Also available in: Atom PDF