Make listing users and groups a privileged endpoint

[sharkymark]

Objective

• Regular members on coder will not be able to list or read other members/users.
• To maintain good UX, context information of created_by will be kept on templates, workspace builds, etc. This will require the read permission on the primary resource being fetched. Included user info will be username and avatar_url.
• A new route will be added to list username + avatar of all users. This endpoint is only usable if a user has "admin" perms on a given template so they can adjust the permissions for said template.

---

Related:

• Limit member visibility for non-admins #4318
• A user who is only a member can see the Users tab, all users, and all groups #4550

Version: v0.12.5+165b6fb

I'll post again for visibility but it seems like an anti-pattern to show the Users UI to any user.

This view shows users' roles so a form of social engineering could occur.

Groups are shown as well, which does seem secure.

If the other issue is being worked, great, but empathizing again.

Lastly, if a large deployment, this is a waste of DB calls if someone bounced onto it.

[Emyrk]

We need to change this assumption and correct the db calls:

coder/coderd/rbac/builtin.go

Lines 204 to 205 in 88e24db

	ResourceType: ResourceGroup.Type,
	Action: ActionRead,

[mtojek]

I can take this task unless somebody else planned to work on it. I see 2 approaches we can apply here.

Approach 1: Normal users don't see the Users tab

1. Site: Hide the Users tab
2. Backend: check user permissions while accessing Users API and Groups API.

Approach 2: Leave Groups sub-tab

1. Site: Leave the Users tab, but hide the sub-tab Users.
2. Site: Remove the Users column (avatars) from the Groups sub-tab. Theoretically, you can use this information to figure out who is the admin.
3. Backend: check user permissions while accessing Users API.
4. Backend: remove user references (avatar, login, email) from the Groups API.

@sharkymark Which approach do you think will be more convenient for customers? From a security perspective, it depends if there can be secret groups, which should be hidden the same way as users.

Side issue: Groups API and User API return email addresses. I have a feeling that we should limit this behavior...

[klauserber]

We are running IT workshops on coder (#5058) and on every workshop start I have to talk with the participants about leaking there eMails addresses or may use fake addresses to register.

Would be good to know if and how this behaviour will be changed in future. May we have to use 'synthetic' emails addresses for every user, but this is a more or less ugly workaround.

With other words, a solution from coder would be very nice.

[Emyrk]

Just want to add if we remove the read permission from User resource, we should also do something about the organization-member role.

I wonder if this is something orgs can do. Preventing users from seeing members in different organizations.

[Emyrk]

@sharkymark Should we always hide groups? Should there be public and private groups? Should we show private groups if you are a member? Should we hide all users always to other members?

[bpmct]

Should we always hide groups?

Let's only show user what groups they are in, perhaps in the account dropdown as pills.

Should we hide all users always to other members?

would users be able to join public groups? is that how it works? I don't think we need to do this immediately

Should we hide all users always to other members?

yes

Should we show private groups if you are a member?

Let's only show user what groups they are in, perhaps in the account dropdown as pills.