[wp-trac] Re: [WordPress Trac] #6014: Users given the 'edit_users' capability can alter and create new users above their user level.

WordPress Trac wp-trac at lists.automattic.com
Fri Mar 14 00:47:07 GMT 2008


#6014: Users given the 'edit_users' capability can alter and create new users
above their user level.
--------------------------+-------------------------------------------------
 Reporter:  jeremyclarke  |        Owner:  pishmishy
     Type:  defect        |       Status:  assigned 
 Priority:  normal        |    Milestone:  2.6      
Component:  Security      |      Version:           
 Severity:  major         |   Resolution:           
 Keywords:                |  
--------------------------+-------------------------------------------------
Comment (by jeremyclarke):

 Replying to [comment:4 pishmishy]:

 > Now we're considering rare edge cases. We could also end up with weird
 situations whereby a user A with edit_users capabilities but without
 capability "x" could give edit_users capabilities to a user B with
 capability "x" who would then give capability "x" back to A. It's almost
 certainly not a situation that the administrator intended, and not
 intuitive.

 This is a valid edge case where my system doesn't behave exactly as
 expected, but it is just that, an edge case, and an extreme one at that. A
 responsible administrator would ensure that no one has permissions that
 the edit_users-ified users weren't allowed to have (like say
 "manage_plugins" or "manage_options", which in a system with many users
 are likely only needed by a small handfull). It is so unlikely to happen
 that I can't take it very seriously actually, and if it did happen the
 administrator could fairly easily fix the situation by modifying the
 existing permissions to be hierarchically consistent.

 My personal edge-case on the other hand is not nearly as extreme. All I'm
 asking is that an administrator be able to allow non-admins to create and
 edit users of a role lower than theirs. This is not a controversial
 behavior or an unexpected one, it's a completely normal thing to want, but
 right now it is impossible to do within the existing permissions
 structure.

 > Again, I don't wish sound as if I'm dismissing the problem, but this
 really is an issue for the plugin's author. With direct access to the
 database, plugins have the ability to do lots of really stupid things if
 they chose to, and we don't (can't?) spend time worrying about them.


 I think your comment about direct DB access points to the problem here.
 The plugin at hand isn't accessing the DB, or anything like that at all,
 it is using completely standard API calls to manipulate the system
 capabilities in exactly the way envisioned by the coders when they
 designed the system. The problem is that this one specific capability does
 not perform in the way that an API user would expect it to.

 I guess that an API hook could potentially solve this problem by allowing
 the Role Manager (or other) plugin to filter the list of
 capabilities/roles whenever it is generated for use in modifying users,
 but there isnt' any such hook at the moment, at least not in the edit-
 users.php file (which generates the normal user editing screen with the
 pulldown for roles).

 Actually, looking at the code it seems the function wp_dropdown_roles() is
 used in all situations EXCEPT the edit-users page. If this funciton was
 modified to work on that page and an api filter on the list of roles was
 added then the plugin could easily do this filtering for itself in all
 places where the role dropdown is visible.

 That still wouldn't have the desired effect of avoiding edit_users
 privileged people from editing the passwords/information of administrators
 maliciously, but it would at least avoid them giving themselves access to
 plugins/options etc.

 I will try to write a patch to add the filter to wp_dropdown_roles() if I
 can. If anyone is reading this and has advice/recommendations please feel
 free to lay them on me. Would 'dropdown_roles' be the best name for it?

-- 
Ticket URL: <http://trac.wordpress.org/ticket/6014#comment:5>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list