[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
Thu Mar 13 10:29:17 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 pishmishy):
Replying to [comment:3 jeremyclarke]:
> Hmmm, while writing this my thinking was that the user_level's, still
being in use, could be used to create the hierarchy. If you're saying that
the goal is to 100% stop using user levels then I understand how that
complicates any possible solution.
I can't speak on behalf of the core developers, and so can't be certain,
but tracking the development of access control in WordPress it's the
direction that WordPress is taking.
> One thing that I think is important to remember is that in almost all
situations these changes will have no effect. For installs where only
admins have edit_users privileges they will always qualify to make
whatever edits they want.
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.
> Also, the kind of documentation you're describing would be very hard to
implement, and would involve forcing everyone already using the plugin to
read the new documentation (as opposed to having the problem automatically
fixed behind the scenes when they upgrade to the latest wp).
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.
--
Ticket URL: <http://trac.wordpress.org/ticket/6014#comment:4>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list