Users with edit user permission can make themselves admins

[andreasjacobsen93]

Bug Report

Current Behavior
If a moderator is assigned with the permission to edit users, the user is also able to make itself admin by editing and assigning the administrator role to itself.

Expected Behavior
Only administrators should be able to assign or remove the admin role on a user.

Environment

• Flarum version: 0.1.0-beta.11.1

[tankerkiller125]

I can confirm that this issue is valid both on nightly, beta, and my own forums.

Something very interesting to note is that they can make themselves Admins, but they can not remove Admin from themselves. When trying to remove the permission from themselves the moderator (turned admin) will receive a 403 error.

[dsevillamartin]

How we'd want to solve this would be to prevent users from giving a group to anyone, including themselves, if that group has any permission additional to their own.

This could be solved using a hierarchy like Discord roles.

Separating the user.edit permission could also help. If split, we'd still want to prevent users from giving anyone higher permissions (any that they don't have themselves) than their own.

REQUIRES FURTHER DISCUSSION.

[tankerkiller125]

Personally I'm a huge fan of the way discord handles this problem, however depending on how in depth we want to go with "additional permissions" this could become quite complicated to handle. The super easy method is just count the number of permissions the user group has compared to the group their try to add (since most groups have more permissions the higher up you go up the chain) however this wouldn't work for all communities.

The other method I can see is comparing the permissions of the user group and the group trying to be added if there are any extra permissions in the group trying to be added to throw a 403 error. However a down side of this method is that some groups may have extra permissions that don't actually pertain to moderation or admin would also cause a 403 error.

When it comes to separating the user.edit permission I'm a big fan of that as not all communities want moderators to have group editing capabilities but they might want the moderators to be able to edit usernames, emails, etc.

[clarkwinkelmann]

Problem about splitting users.edit into sub-permissions, is that it actually doesn't solve the underlying issue (by itself, see below):

• If you can edit groups, you can promote yourself as described in the original report here.
• If you can edit emails, just temporarily edit an admin email, log into their account, change your own groups, then revert the email. No one will notice.
• If you can edit passwords, edit an admin password, log into their account, change your own groups, and hope the admin doesn't realize their password was changed maliciously.

Only username edit could be separated into its own permission. I can't think of any way someone with that permission could promote themselves or hijack another account.

Seems like most importantly, we should make sure only admins can edit other admins, and that only admins can give an admin role. It won't prevent smaller cases of rights escalation (like a community manager promoting themselves as moderator for example), but at least it would prevent anyone from rising up to admin.

Only allowing admins to give admin role actually requires quite a more complex code. Right now we only check "can you edit groups"? then allow whatever. If we want a user to edit groups, including editing groups of an admin, but not allow them to remove or add admin, then we will need a check for each group individually. At that point we might was well implement a full group hierarchy system 😅

EDIT: my suggestion:

• Split permissions into "edit username", "edit credentials" (email + password) and "edit groups".
• AND change "edit credentials" so that non-admins can't edit admins

This should cover a lot of cases. This way only "edit groups" remains as the dangerous permission, until we decide on a proper way to allow giving/removing groups.

[tankerkiller125]

I like your suggestion a lot, and splitting the permissions like that makes a ton of sense. And until we figure out the "perfect" way of handling permissions I think it would be a perfect solution.

[Yalfoosh]

From my perspective the above proposed group editing permission is ill-conceived. The way I see it, group members are equals. Therefore, you should not deal with which group has the permissions to edit groups (you should leave that exclusively for the admin), but rather should shift edit group permissions to a local, inviting and voting model.

Ex., my vision of groups is a system which can allow group members to invite others to a group (with or without requiring admin approval) and which has a vote kicking system (adjustable to a majority, supermajority or absolute majority).

The creation and removal of groups should be administrator-exclusive powers, as well as group editing. The membership aspect of a group should be managed by the members of the group. That way you can have a heterogenous group system where even administrators couldn't abuse their powers to remove other administrators.

Once an administrator creates a group and adds someone to it, the administrator already offered his/her trust in the person to do the role correctly. Therefore, it should be assumed that the person that was entrusted this power is acting towards this goal and that he/she can also manage memberships in a way to reach that goal. However, in such a group there shouldn't be a central power - members should only define a group and act within its scope, but the administrator should be the one deciding whether or not it's going in the right direction, and should therefore be the only central power since the group's power originates from the administrator.

The only bad thing is that this would require somewhat of a rewrite of the whole system, and that there are still way to abuse the invite system (but for groups with critical permissions there is always the option of administrator approval). This way, however, you can completely ignore hierarchy (except the absolute one, the administrator), and other things like suspensions and moderation should be solved separately. Perhaps some system like this would become an interest once Flarum reaches stable?

[clarkwinkelmann]

@Yalfoosh I think your suggestion is too far from the current issue, as it basically require re-writing the whole concept. This is a fantastic idea for an extension, but this seems too complex and opinionated for core. I believe most forum software use a similar "absolute" power for managing all moderation roles. You usually don't want people to be able to vote their way into roles with access to user editing functions.

The question at hand here was how to split permissions and what limits to put on each permission so that you can give moderators some of that power without them being able to promote themselves to admin or hijack admin accounts via those permissions.

[Yalfoosh]

@clarkwinkelmann I understand, and that's why I argued that moderators shouldn't even need such permissions. If they want to recruit a new moderator, they could invite that person and then an administrator would have to approve said invitation. After all, the administrator has to approve of a new moderator even now, so there wouldn't be any difference. There would be no way for them to abuse such a system because there wouldn't be any permissions to abuse.

For every other role you could have automatic group management without approval, and that's a bonus this system brings - you don't need the presence of an administrator or a moderator that might not be that affiliated with said group, so an administrator can create user groups that might create micro-communities and manage themselves. For an example, this could be useful in the case of student groups.

If we look for a solution purely via permissions, then adding hierarchy will be necessary sooner or later, since groups aren't self managed and there is no implicit hierarchy like in the system I proposed where administrators are implicitly higher in the hierarchy than other users.