[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