Problem/Motiviation

When using a combination of Views Bulk Operations and the Administration VIews modules, a bug occurs where users can circumvent the role delegation restrictions.

They can do this by selecting users from the admin/people page and then choosing 'Change user roles' from the bulk operations drop down. The VBO form then allows them to add/remove all roles in the system.

Proposed Resolution

Apply a hook_views_bulk_operations_form_alter to the VBO form provided by Administration VIews, removing any roles the user does not have access to.

See attached patch file.

Thanks to https://www.drupal.org/u/mhz for the consultation on this.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

danielmrichards created an issue. See original summary.

danielmrichards’s picture

danielmrichards’s picture

Issue summary: View changes
benjy’s picture

That action is exposed with a combination of those two modules, which bypasses the fact that core has a permission called administer permissions. It is for VBO to either access check the action or Admin Views to add stricter permissions to the view.

danielmrichards’s picture

Hi @benjy, yes I agree with your comment, those modules should provide stricter permissions on the view.

But what about the use case where we want a 'user manager', for example, to bulk assign roles they have permissions for? Then surely role_delegation should hook into the VBO form to remove any/all roles they do not have permission to assign?

benjy’s picture

If those modules were doing what they were suppose to and your user manager role didn't have administer permissions, then the assignable roles via VBO would be empty. If that was the situation, we could consider, re-adding the roles for which they has the permission to assign or maybe we'd just provide our own VBO action.

danielmrichards’s picture

Hmm, fair point. There have been open issues with VBO and Admin views regards this issue (https://www.drupal.org/node/2564855) in the past, but seem to have been ignored. Admittedly it is a bit of an edge case; so I'll defer to you on this one.

Feel free to close this issue if you prefer :)

ron_s’s picture

Version: 7.x-1.1 » 7.x-1.x-dev
FileSize
1.56 KB

Maybe I'm missing something here, but it seems as though there is an issue. In the role_delegation_delegate_roles_action_form function, it uses _role_delegation_roles to build the form fields.

_role_delegation_roles always returns all existing roles, except anonymous and authenticated user. Therefore the action form shows all roles in every situation, regardless of permissions.

I would think there needs to be a conditional in the action form as shown in the attached patch. Would appreciate feedback, thanks.

ron_s’s picture

Status: Active » Needs review

Marking as needs review.

ugintl’s picture

Patch does not apply

ron_s’s picture

Yes, it does apply. We've been using this patch for almost 3 years, I'm sure it works.

It needs to be applied to the -dev version, not the released version.

JeroenT’s picture

ron_s’s picture

Yes, the patch in #2051669 is identical.