I have a role with Administer users permission on and permission to add certain roles with Role assign -module. With this role, Administrator role selection is visible in Configuration >> People >> Account Settings. I think this selection should not be accessible to role with only Administer users permission on.



salvis’s picture

Status:Active» Postponed (maintainer needs more info)

I have a hard time following your description. Please use concrete names, something like "I have a role named Webmaster with the Administer users and Assign roles permission, etc."

With this role, Administrator role selection is visible in Configuration >> People >> Account Settings.

Try "A user who has the Webmaster role sees ... " — What exactly does he see? on what path (=URL without hostname)? Screenshot? What do you expect him to see instead?

timomoilanen’s picture

new37.98 KB

Ok, I try to be clearer :)

I have a role named Webmaster with Administer users permission and Assign roles permission.
A user who has this Webmaster role can access Administrator role -selection in Home » Administration » Configuration » People (see screenshot)
I think user with these permissions should not be able to see this.
Does this help to understand the problem?


akalata’s picture

Status:Postponed (maintainer needs more info)» Active
salvis’s picture

Title:Administrator role selection is visible in Configuration >> People >> Account Settings» Administrator role selection is visible in admin/config/people/accounts
Category:bug» task

Thank you for explaining. This is surprising, indeed!

It is an issue in core (not in RoleAssign), and I checked with the Security Team whether it was a security issue (hence the delay). They say it's not, because exploiting it would require a compromised account with 'administer users' permission, meaning the site would already be broken.

In the context of Core this is maintainable, because 'administer users' opens all doors. The situation is different if you use RoleAssign to restrict the power of 'administer users', and I agree that we need to fix it. Stay tuned...

salvis’s picture

Title:Administrator role selection is visible in admin/config/people/accounts» Hide the Administrator role selection in admin/config/people/accounts unless the user has the 'administer permissions'

#1367442: Fix Core for D7 has a fix for this issue.

Please let us know how it goes.

salvis’s picture

Status:Active» Fixed

No follow-up — feel free to reopen if needed.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

jlbretton’s picture

new29.99 KB

Similar to this issue.
I have a role named Webmaster with Administer users permission and Assign roles permission.
A user who has this Webmaster role can access admin>people, and delete the admin users using the Update option --> selecting "Cancel the selected user accounts" or block the Admin user with "Block the selected users".
A none Admin role shouldn't be able to access those 2 options.
Thank you

salvis’s picture


Yes, somewhat similar, but it doesn't really belong here. RoleAssign's job is to make sure that no deputy administrator can upgrade himself by assigning permissions that he's not supposed to assign. Changing the Administrator role to a role that he holds would allow him to acquire future permissions, which makes the original issue in this thread a RoleAssign issue.

However, protecting administrator roles against Denial of Service attacks is beyond RoleAssign's tasks. It's clearly a job for the Protect Permissions project, which aims to be an install-it-and-forget-it solution. I have clarified that project's description to explicitly mention bulk operations.

jlbretton’s picture

Thanks for the clarifications Salvis.
I will try PP when ready to test, seems promising. In term of job functionality I understand your point. But in term of end users use case, it would make sense to have at least a part of the PP functionality into RoleAssign.
Would'nt it make sense to clarify the current "limitation" of Roleassign, or even better, make it a subset of your PP module?
Thanks you for your great work.

salvis’s picture

AFAIK RA does what is needed to keep RA-restricted users with the 'admin users' permission from obtaining additional permissions. This is all it claims to do and how far it goes. If you need more, then you need the full PP — parts of it won't do.

I originally planned to make RA and PP disable each other because they partially overlap, but you've convinced me to try to get them to coexist. If I can get this to work, then I'll certainly point to PP for more complete protection.

Steve -cc’s picture

I have created a role of "manager". I want the user/s with that role to be able to assign lower level roles to other users. It appears to me that the "manager/s" would need to have "Administer Users" permission to use Role Assign to assign roles to other users.

When I don't give the manager role "Administer Users" permission then they do not have access to people and add users.

When I do give them "Administer Users" permission they can add users and assign roles but also seem to have the ability to cancel my super-user account.

That does not seem good / safe to me. It seems like that is what this thread is all about. Has any progress been made. Is this module still an active project?



salvis’s picture

Your concern is a valid one, but it does not belong in this issue, which was completed a year ago.

What makes you think there should be "any progress" or any cause for concern about the project state in a closed issue?

Have you tried out your assumption? Please do, and open a new issue if you feel the need to pursue this further.

Steve -cc’s picture

Thanks salvis. I will do that


natan_dz7’s picture

I'm working with Drupal 7 and I need to do exactly that, disable "Config> People> Account options" for some roles, but the module "Protect Permissions" is no longer available for download. How can I solve this?

salvis’s picture

I wish I had time to work on Protect Permissions...

RoleAssign protects the Administrator Role — that's all we have at this point.

rimu’s picture