[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