Execute as User 1 - skip permission step

Yes, I like this idea.

Me too! This already happens in the Drush integration btw.

Bumping because I need to list some nodes in Rules that requires a filtered view.

#1310228: Can't execute a rule without "Administer Users" permission

Here's a patch that adds an option to skip the permission check per individual action.

I was initially thinking of impersonating user 1 right before execution, as in:

  global $user;
  $user = user_load(array('uid' => '1'));
  session_save_session(FALSE);

Any opinion as to the pros/cons of each approach?

My thinking was that what if, for example, logging of which user did what was added. Then it may say user 1 when in fact it may not be true. My approach is essentially the same thing. Also everybody may not know that user 1 skips the permission check.

Skipping the permission check is not enough, the trick needs to be #5.
Otherwise entity_access and other access controls will still fail.

But aren't the access controls skipped anyhow when executing as user 1?

Yep. But your patch doesn't do that.

I know that my patch doesn't do that, it was an active choice. :)

My thinking was that if permission checking is skipped when running entity_access, why not just skip the entity_access checking?

Also, some users my not be aware that "execute as user 1" == skipping permission check so I opted for actually skipping the permission checking and be verbose with what the option means.

Is this your suggestion? (in D7)

global $user;
$original_user = $user;
$old_state = drupal_save_session(FALSE);
$user = user_load(1);

//Execute the action

$user = $original_user;
drupal_save_session($old_state);

We can label the option "skip permission check" and implement it as "impersonate user 1".

So the switching back to the real user will be done in _views_bulk_operations_execute_finished?

How should I have the $old_state available there. Should I add $user->old_state or another global variable? Or do you have a better approach?

My thinking was that if permission checking is skipped when running entity_access, why not just skip the entity_access checking?

I agree with emattias' strategy here as it doesn't muss about with user object switching and session saving. It's simple and effective.

I implemented this patch and it works well and can't really see any problems with it. The only issue I could even imagine would be granting someone permission to admin and build VBO's and from there building a VBO that elevates themselves or others to Administrator role by then skipping perm checking on the operation. But you're likely not giving VBO admin rights to someone who can't be trusted with user admin anyway?

@westie, Yes. Someone could be sandboxed to admin Views/VBO, then build a VBO that changes alters the roles of the users returned to Super Admin role or something. Click "Skip permission checking" so it wouldn't bother to see if they have "admin users" or Role Delegation permissions, and elevate their user to Super Admin, and from there do whatever the heck they wanted.

But it would initially depend on them being trusted enough to have Views/VBO admin perms to begin with.

Anybody can answer #10 and #11 about how to implement this to have the action executed and revert at the end of the action to the user 1.

Just so you know content access module has Grant/Revert access actions compatible with rules. However they do not work in rules components within action sets. May be it can be an avenue instead of hacking the code to impersonate user 1 by granting access before the action and reverting the access to regular at its end.

but i don't think it is necessary to impersonate a 100% the admin as the only permission usually needed to execute a bulk operation on a node is Edit any content.

Edit: Nevermind, #18 takes care of it.

Reworked the patch to suit the current -dev. Various changes like $form['vbo']['operations'] is now $form['vbo_operations'] incorporated.

Also, it still wasn't solving my problem, which is that the action didn't even show as an available action to anyone but user1. I reworked the permission check in get_selected_options() to account for the permissions skip.

#18 works for me , it solve the whole problem

Can I just clarify if the #18 patch allows users other than admin (uid: 1) to execute rules component actions?

I have a view that shows only the nodes the author created and I would like for them to be able to execute rules component actions on their own nodes.

EDIT: I have found my solution. I am using Rules Link module instead.

Submitting the patch for release 7.x-3.2

Here is another patch for branch 7.x-3.x

Patch applied to 7.x-3.2 worked beautifully for me, thank you!

I test patch #22 applied on stable release 7x.3.2

Works as advertised, this was exactly what we needed.
Ready to be integrated in dev and next release.

Our use case:
Normal users can not edit or create a specefic field.
But they can assign one trough VBO that calls a rule action with lots of goodies.
The skip permission power does travel the complete rule chain.

thx

I applied the patch (21) successfully to 7.x-3.2. Should I see an extra option under each VBO choice in the view to turn this on? For example 'Execute as user 1' ? I do not see this.

Working now. Many thanks to the submitters!

When will there be a new stable release?
I saw its been more than a year and there are a lot of patches added already.

I applied this patch and it was working, but seems to have just stopped appearing for me. The option is no longer in the view. Anybody else see this?

@eswiderski

Did you have automated updates or something like that, you have to reaplly the patch eatch time you replace the code with a different version.
Clear cach?

Still working at our end.

@ikeigenwijs

what version/patch combo are you guys using?

thanks!
ed

@ikeigenwijs good call it was probably an update. just patched latest stable with 22 and it's back.

thanks!

It would be nice if it would get commited...

Patch in #22 also works for version 3.3.

This patch needs work because currently all existing views that use VBO will be broken:

Fatal error: Call to a member function getAdminOption() on boolean in /.../sites/all/modules/contrib/views_bulk_operations/views/views_bulk_operations_handler_field_operations.inc on line 305

This is probably caused by getAdminOption which does not receive a correct value for the setting, because the view was never saved.

Quick fix is to resave all exisiting views, after editting the VBO settings (for each display).

Solution would be to patch getAdminOption() or include an update.php script which would update all exisiting views.

edit: no need for that, just need to check if $operations exists, something like attached patch.

This patch should be combined with the patch in #22.

Looks good

patch doesn't apply to latest dev.

Here's a reroll, which combines #22 and #35 against latest dev.

Thanks for the re-roll @aaronbauman, could you make the patch relative to the module's root please? Inside views_bulk_operations when you are making the patch use --relative flag on git diff --relative .

Ooops, that's my bad.
Here's a re-reroll

Still looks good on current dev.
We are using this for about 9 months on a production environment with +- 3 million nodes so we use vbo a lot.
Would be nice to have this committed.

Still works with the dev from Nov 28 2015

#41 is perfectly working with VBO version 7.x-3.3. Please commit this patch to the dev release.

Instead of #5 (which is valid for drupal6 only) the instructions in https://www.drupal.org/node/218104 worked for me (I wanted to "execute as user 1" in Rules). They contain the code for both drupal7 and drupal8. This may be helpful / an alternative to the patch above which only refers to VBOs

#41 works for me, too, using 7.x-3.3.

FWIW, I needed this patch because I'm writing a custom action that will create nodes using data from a view, but the user performing the action will never have permission to alter the data in the view itself, which is what VBO is normally used for. I couldn't figure out a way to work around this without skipping VBO's permissions checks entirely.

#41 works for 7.x-3.3.

Still applies cleanly on current dev

A screenshot of the UI addition.
No change or impact for current installs and views.

#41 works perfectly. Thank you very much

works for me :-)

It's been over 14 months since this issue was marked RTBC.

Could we get this committed to the module code, please?

The code looks good, just reviewing the functionality and will likely commit tonight or tomorrow.

Committed and pushed to -dev

Is this in D8 dev version?