It seems that a user with that permission can access all sorts of funny places such as:

/admin/config/people/accounts

Where they can pretty much destroy the whole site from :/

Files: 
CommentFileSizeAuthor
#14 remove_administer_users_dependency-1717876-14.patch6.03 KBpc-wurm
PASSED: [[SimpleTest]]: [MySQL] 1,141 pass(es).
[ View ]
#13 remove_administer_users_dependency-1717876-13.patch6.03 KBpc-wurm
PASSED: [[SimpleTest]]: [MySQL] 1,141 pass(es).
[ View ]
#11 remove_administer_users_dependency-1717876-7-11.patch1.67 KBpc-wurm
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch remove_administer_users_dependency-1717876-7-11.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#9 Bildschirmfoto-15.png37.63 KBfraweg
#7 remove_administer_users_dependency-1717876-7.patch5.21 KBBWPanda
PASSED: [[SimpleTest]]: [MySQL] 1,141 pass(es).
[ View ]

Comments

Only tested on drupal 7.14.

Agreed, this seems like a good way to destroy your site. A user with administer users can also access the 'Manage display' and the 'Manage fields' local tasks which allow them to cause all sorts of trouble.

Users with 'adminster users' disabled cannot create new users. This behavior is hardcoded in core user.module, 'adminster users' is checked when user_register_form is built.

Subuser module gets around this with hook_menu_alter and then its own access callbacks. See below:

/**
* Implements hook_menu_alter().
*/
function subuser_menu_alter(&$items) {
  $items['admin/people/create']['access callback'] = 'subuser_access_create_callback';
  $items['user/%user']['access callback'] = 'subuser_access_view_callback';
  $items['user/%user/cancel']['access callback'] = 'subuser_access_delete_callback';
  $items['user/%user/cancel/confirm/%/%']['access callback'] = 'subuser_access_delete_callback';
  $items['user/%user/edit']['access callback'] = 'subuser_access_edit_callback';
}

Also, I think if its going to remain with just using the administer users permission it should at least warn people what a can of worms that opens up.

Agreed. Enabling administer users is far too risky. Checking out http://drupal.org/project/subuser

Adding the Field UI permissions module to the mix certainly seems to help. At least then you can control which roles can get their grubby mits on 'Manage Fields' and 'Manage Display' for user entities.

http://drupal.org/project/field_ui_permissions

Status:Active» Needs review
StatusFileSize
new5.21 KB
PASSED: [[SimpleTest]]: [MySQL] 1,141 pass(es).
[ View ]

Here's a patch that removes the dependency on the 'Administer users' permission (mostly copied from the Subuser module).

I removed all references to the 'administer users' permission from the .test file, however as I have no idea how to run tests, I'm not sure if they still pass or if I've messed them up...

Hello,

is the actual dev version patched with #7 ?

Best regards
Frank

Edit:

I have test to patch the actual dev version and get this output:

:/$ patch -p1 < remove_administer_users_dependency-1717876-7.patch
patching file administerusersbyrole.info
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file administerusersbyrole.info.rej
patching file administerusersbyrole.module
Hunk #2 succeeded at 191 (offset 6 lines).
patching file administerusersbyrole.test

Did I something wrong? And also the "add user" permission does not work without enabling the "administer user permission"
Have I to do something else?

Mea culpa! After clearing the cache it works. But the "Hunk #1 FAILED at 1." still exist.

StatusFileSize
new37.63 KB

Ok...now the add role feature seems to work. But when I create the user I have two fields to assign a role to the user as you can see it in the screenshot. Any Idea what to do?

Best regards
Frank

Edit: Sorry...this was an issue with role delegation

I used patch in #7 on the git commit 9a4ee4a3ed9d8bc9c8f51b1e1257eb8a0aa784c2.

The change does allow the selected role to add and edit users without the broad administer users permission. But it also provides access to the permissions page even though the role doesn't have the permission "administer permissions", which is an even bigger security issue.

If you remove this line from the patch:

$items['admin/people']['access callback'] = 'administerusersbyrole_access_create_callback';

then it removes access to admin/people, admin/people/* except for admin/people/create which is still explicitly listed.

Title:Enabling adminster users = bad advice!!!Enabling administer users = bad advice!!!
StatusFileSize
new1.67 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch remove_administer_users_dependency-1717876-7-11.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Patch #7 works!

However, I found out that the users with 'create users' permission cannot view blocked users. So that, for example, a user with 'create users' permission but without 'administer users' permission can create a user, set his status as blocked (in my case for a peer review for example), and if he wants to view the users account that he just created, he gets access denied message.

I have extended the patch #7, and attached it, but it is not a merged patch, it requires first the patch #7.
If someone can merge these patches (after reviewing) I would be grateful.

Status:Needs review» Needs work

The last submitted patch, remove_administer_users_dependency-1717876-7-11.patch, failed testing.

Status:Needs work» Needs review
StatusFileSize
new6.03 KB
PASSED: [[SimpleTest]]: [MySQL] 1,141 pass(es).
[ View ]

Ok, here's the merged patch. This patch contains the patch #7 and enhances it with the solution of the problem described on the comment #11.
----
EDIT: Please ignore this patch, it has a typo. Use the next patch I am going to post.

StatusFileSize
new6.03 KB
PASSED: [[SimpleTest]]: [MySQL] 1,141 pass(es).
[ View ]

Here is a revisited version of the previous patch.

Which commit was this patch #14 for?

The latest dev version from 2013-May-14. I did also a few other patches in my local installation. If the patch doesn't apply correctly because of the line numbers aren't matching, please try to apply the changes manually and provide a new patch.

Good alternative solution: drupal.org/project/user_settings_access

Title:Enabling administer users = bad advice!!!Remove dependency on 'Administer users' permission
Issue summary:View changes

Status:Needs review» Needs work

Patch applies to latest dev. I am able to create but not edit a user.