[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
Wed Mar 12 18:44:33 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):

 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.

 Here's another option, what if users editing other users cannot give them
 any role that has a capability that they do not have, nor can they add
 capabilities that they themselves to do not have. It would stop the
 negative behavior I described without affecting the ability of middle-
 admins to take a load off of the administrators in managing users (with
 the ultimate goal of limiting the number of admin accounts in the system
 to those people who actually need to modify options and plugins etc. which
 has inherent security benefits)

 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.

 I'm open to the idea that this is an innapropriate goal for wordpress to
 aim at (Because WP "insn't a cms" or something, which I don't believe but
 recognize is an opinion some people have), but I think that it is
 definitely possible within the system, and the whole existence of the
 edit_users capability implies that it should work for users that don't
 nevessarily have root control of the system. 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).

 Thanks for showing interest in the ticket pishmishy.

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

More information about the wp-trac mailing list