feat!: drop reading other 'user' permission

[Emyrk]

Blocked by: #8625
Closes: #5002, https://github.com/coder/v2-customers/issues/232

Members of the platform can no longer read or list other users. Resources that have "created_by" or "initiated_by" still retain user context, but only include username and avatar url.

Attempting to read a user found via those means will result in a 404.

Groups are also now a privileged endpoint.

Admins via template ACL

If a user is given admin to any template, that user can still see the users + groups listed in the template permissions. This is done via a new /template/<template_id>/acl/available endpoint.

UI

No more Users tab for regular users

[BrunoQuaresma]

LGTM

[johnstcn]

We should add unit tests in this file to assert this new behaviour.

[Emyrk]

Which new behavior exactly? The rbac stuff is all tested.

I will add a test for the acl available EDIT: Added for acl available endpoint

[johnstcn]

While the RBAC stuff may be unit tested, we also need to ensure that the behaviour is as desired at the API endpoint level.

My understanding of this PR is that it removes the ability of org members to read other org members. Is this understanding correct?

If so, I suggest adding test cases to cover the following:

• As an org member, I can read my own user by ID.
• As an org member, I can read my own user by name.
• As an org member, I cannot read another org member by ID.
• As an org member, I cannot read another org member by name.
• As an org member, I cannot list all users in the org.
• As an auditor, I can read another org member by ID.
• As an auditor, I can read another org member by name.

[Emyrk]

My understanding of this PR is that it removes the ability of org members to read other org members. Is this understanding correct?

Yes. You cannot read other org members or other users. This matrix of who can read who is tedious to test at the api level. So I have matrix tests that answer those questions.

Org Member matrix

coder/coderd/rbac/roles_test.go

Lines 290 to 298 in 39912a2

	{
	Name: "ReadOrgMember",
	Actions: []rbac.Action{rbac.ActionRead},
	Resource: rbac.ResourceOrganizationMember.WithID(currentUser).InOrg(orgID).WithOwner(currentUser.String()),
	AuthorizeMap: map[bool][]authSubject{
	true: {owner, orgAdmin, userAdmin, orgMemberMe, templateAdmin},
	false: {memberMe, otherOrgAdmin, otherOrgMember},
	},
	},

Read user matrix:

coder/coderd/rbac/roles_test.go

Lines 106 to 123 in 39912a2

	{
	Name: "MyUser",
	Actions: []rbac.Action{rbac.ActionRead},
	Resource: rbac.ResourceUserObject(currentUser),
	AuthorizeMap: map[bool][]authSubject{
	true: {orgMemberMe, owner, memberMe, templateAdmin, userAdmin},
	false: {otherOrgMember, otherOrgAdmin, orgAdmin},
	},
	},
	{
	Name: "AUser",
	Actions: []rbac.Action{rbac.ActionCreate, rbac.ActionUpdate, rbac.ActionDelete},
	Resource: rbac.ResourceUser,
	AuthorizeMap: map[bool][]authSubject{
	true: {owner, userAdmin},
	false: {memberMe, orgMemberMe, orgAdmin, otherOrgMember, otherOrgAdmin, templateAdmin},
	},
	},

These cover all the cases you just asked.

The OrgMember RBAC object is defined here:

coder/coderd/database/modelmethods.go

Lines 194 to 200 in 39912a2

	func (m OrganizationMember) RBACObject() rbac.Object {
	return rbac.ResourceOrganizationMember.
	WithID(m.UserID).
	InOrg(m.OrganizationID).
	WithOwner(m.UserID.String())
	}

And then it is asserted the db makes the right checks in the dbauth_test.go:

coder/coderd/database/dbauthz/dbauthz_test.go

Lines 533 to 538 in 39912a2

	s.Run("GetOrganizationMembershipsByUserID", s.Subtest(func(db database.Store, check *expects) {
	u := dbgen.User(s.T(), db, database.User{})
	a := dbgen.OrganizationMember(s.T(), db, database.OrganizationMember{UserID: u.ID})
	b := dbgen.OrganizationMember(s.T(), db, database.OrganizationMember{UserID: u.ID})
	check.Args(u.ID).Asserts(a, rbac.ActionRead, b, rbac.ActionRead).Returns(slice.New(a, b))
	}))

---

So these tests cover that any db calls for a given resource as a given actor are correct according to that list you mentioned.

The test I added was the ACL listing available users/groups because it uses dbauth.AsSystemContext to get around the permissions and keep the UX if you are an admin for a given template. I imagine we might need to revisit that in future based on certain feedback, but it was required to keep the UX the same.

[johnstcn]

I would also really like to see tests at the coderd package level for this change.
That can be done as a follow-up if required, but it would increase confidence and solidify the behaviour.

[Emyrk]

It would increase confidence for sure.

We don't do these style RBAC tests at the coderd package layer atm except in very few cases. Most of our coderd tests run as Owner ☹️.

I'd prefer not to have to write all these, because ideally I wouldn't write new tests, but run the existing tests as various actors and assert various outcomes. But that requires refactoring the tests for fetching users, groups, etc 😢.

Essentially, I think if we are going to test these kinds of things at the coderd level, we should do it in a way that doesn't just add a lot of test code bloat.

[Emyrk]

There might be an issue we should make at some point to audit the rbac assertions in our unit test for correctness.

The current various series of tests are loosely coupled for sure and probably are missing things or have bugs.