When a user role is granted 'administer users' permission this allows them to not only edit any users profile, but also amend the access control list, even for their own role. This means a moderator could actually increase their own permissions to enable further access to Drupal site settings.
To prevent this I have split the user module permissions further to provide a new permission setting for each role - "administer permissions". Enabling this permission for any role will provide the user with access to the "access control" pages and functionality.
Patch attached to add additional permission and change menu access checks as needed.
Comments
Comment #1
nedjo+1 on idea (I haven't patched and tested), makes sense to me as a distinct permission.
Comment #2
allie micka+1 from me also, although I also haven't tested the patch. This "escalate myself" privilege is a big problem!
Comment #3
Chris Johnson commented+1
This seems like a real requirement for proper permissions handling.
The patch looks good from a code review, but I have not tested it yet.
Comment #4
killes@www.drop.org commentedI've upated the patch to make it work from the root directory. I also fixed a minor formating issue.
While I think that this patch is usefull, I think it isn't general enough. Once you got the "admin users" permission you can grant yourself any defined role. So this patch is only usefull if none of the defined rules has all permissions. I have a number of sites where this would be sufficient, but we try to keep Drupal usable for all use cases. Applying thi spatch as it is now would mean to pretend false security in a lot of cases.
Comment #5
Bèr Kessels commentedSo, what would be ''the'' solution?
* only allow users with a role one ' above' the to-be-changed-user to change that user? And in that case, how to find the one-above in drupals non-hierarchical user system,
* only allow users with one role to lever themselves> the patch tries this, but essentially does not fix the issue. anyone with ''administer permissions'' can now leverage himself.
* allow only uid1 to dedicate users that can change permissions? which can be a problem in big environments?
I cannot see any real solution, IMO the *nix solution, the sudo, is the best one: just introduce a role that can act like uid 1, and leave permissions to my 3rd solution.
but in that case this issue whould have to be moved and renamed.
Comment #6
killes@www.drop.org commentedI think a possible solution would be to take "chenge roles" out from the "administer users" permission and move it to the proposed "administer permissions" permission. Ie you can only change roles if you can change permissions. This would make sense to me. People who have "administer users" permission but not "administer permissions" could still change other user settings.
Comment #7
buddaKilles: isn't this what the patch is doing already?
Comment #8
killes@www.drop.org commentedno. there are no changes to user_edit_form
Comment #9
JoranLawrence commentedI am sort of a newbie to Drupal, so excuse my intrusion in a clearly high-level drupal development discussion. However, I need this functionality for a project and have thought about the issue/problem. While my suggestion might not be a realistic solution (because of the drupal core); it might move the conversation towards one.
I think Roles should be able to carry a weight attribute.
Reason 1: It could used to print the 'permissions' page of the access control in a logical left to right (less to more) access based on weight.
Reason 2: The same logic above would be used so a user could only change permissions for less weighted roles than their maximum assigned role.
Reason 3: Users could not assign themselves to roles beyond the weight of their assigned role.
I have not looked closely at the code of user.module or the patch, so I don't know how difficult this would be to implement. However, I think this functionality is critical. I would love to see it 4.7. If there is anything I can do to help, please let me know.
Comment #10
moshe weitzman commentedi agree that ordering user roles isa good idea for the reasons you mention. it solves this need in the cleanest way IMO
Comment #11
dopry commentedfrom the peanut gallery:
+1 on role weighting.
+1 to moving change roles to administer permission from user permissions
So you could grant a user change role permissions limited by their own role.
use case: delegate forum administration to a team member, and allow them to grant/remove forum moderation privileges for volunteer/staff members without uid1 intervention.
Comment #12
Jaza commentedIssue no longer relevant - we now have the 'administer access control' permission. Closing.