Make WordPress Core

Opened 3 years ago

Last modified 3 years ago

#21425 new defect (bug)

the 'edit_users' capability also allows 'promote_users'

Reported by: ew_holmes Owned by:
Milestone: Awaiting Review Priority: normal
Severity: major Version: 3.4.1
Component: Role/Capability Keywords: needs-patch 2nd-opinion
Focuses: Cc:


Hello all,

I have found an issue where I have created a Support role in order to have a user make changes to basic user information. What I noticed was that the capability 'edit_users' allows said User (role) to promote users to any role - including admin! I tried removing the cap 'promote_users' and it does nothing.



'read' => true,
'edit_feedback' => true,
'edit_others_feedback' => true,
'list_users' => true,
'edit_users' => true



Change History (3)

comment:1 @nacin3 years ago

edit_users is considered to be a very powerful capability (given, for example, you can change passwords). Only delete_users is more powerful. I'm not against some promote_users checks in both the user-edit.php UI and in the save handler, for more fine-grained control.

comment:2 @ew_holmes3 years ago

Would an additional capability of say, 'edit_basic_users' be a solution? Say it only allows the alteration of the Names, Contact Info, and bio of a user? and remove the ability to change Role, password, and personal options?

comment:3 @firebird753 years ago

  • Cc autremonde75@… added

Thought about it and I think the right way to do it would be to have a filter hook available at the top of the profile page that would allow plugins to filter out each profile field.

It would look like this :

$profile_fields = array('email' => "read-write", 'role' => "read-write", ...);
$profile_fields = apply_filters('profile_page_fields',$user_to_edit);

// then the profile page function would walk through the array to display the fields
foreach ($profilte_fields as $field => $visibility)
    if ($visibility == "read-write")
    // display field with possibility to modify values
    else if ($visibility == "read-only")
    // display field in read-only mode only

This way, plugins could filter out some fields that aren't required by unsetting them or modify the visibility to be read-only for some fields.

The filter would need to be applied also while saving the profile. There, the update function shouldn't update removed fields or read-only ones.

I believe it is important to pass the $user_to_edit to the filter so that the filtering function can check which user is to be modified and based on that, potentially prevent user privilege elevation or not for example.

This filter would allow to get rid of all hacks through the buffering output filtering that take place in several plugins to remove some fields but also to have greater control on what is available to the user or not.

Note: See TracTickets for help on using tickets.