WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 2 months ago

Last modified 8 weeks ago

#21425 closed defect (bug) (wontfix)

the 'edit_users' capability also allows 'promote_users'

Reported by: ew_holmes Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.4
Component: Role/Capability Keywords: needs-patch
Focuses: Cc:

Description

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.

add_role(

'support',
'Support',
array(

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

)

);

Change History (5)

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.

comment:4 @chriscct72 months ago

  • Keywords 2nd-opinion removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Severity changed from major to normal
  • Status changed from new to closed
  • Version changed from 3.4.1 to 3.4

If someone wants to add the hook proposed, a new ticket should be opened for that and the patch for that should be submitted there to keep this ticket on trac. As is, if you need more fined grain control, this is something a plugin could accomplish. That being said when I think about being able to edit a user, I think about being able to edit all of that user, as Nacin said.

Closing as wontfix

comment:5 @nacin8 weeks ago

FWIW - my comment did suggest that we could add some promote_users checks into the UI if they were warranted. I don't know where they are, though. Agree with closing absent a patch or specific suggestion.

Note: See TracTickets for help on using tickets.