RC6 introduced a security fix to prevent users from masquerading as users no in their list by entering them via autocomplete. Unfortunately there is no exception for administrators. This means that an administrator can no longer masquerade as an arbitrary user -- only as users listed in the block.

In masquerade_block_1_validate:
OLD

  $allowed = FALSE;
  $to_uid = db_select('users', 'u')
    ->fields('u', array('uid'))
    ->condition('u.name', $name, '=')
    ->execute()
    ->fetchField();
  if ($to_uid !== FALSE) {
    $allowed = db_select('masquerade_users', 'm')
      ->fields('m', array('uid_to'))
      ->condition('m.uid_to', $to_uid, '=')
      ->condition('m.uid_from', $user->uid, '=')
      ->execute()
      ->fetchField();
  }
  if (isset($_SESSION['masquerading'])) {
    form_set_error('masquerade_user_field', t('You are already masquerading. Please <a href="@unswitch">switch back</a> to your account to masquerade as another user.', array('@unswitch' => url('masquerade/unswitch', array('query' => array('token' => drupal_get_token('masquerade/unswitch')))))));
  }

SUGGESTED:

  $allowed = FALSE;
  $to_uid = db_select('users', 'u')
    ->fields('u', array('uid'))
    ->condition('u.name', $name, '=')
    ->execute()
    ->fetchField();
  if ($to_uid !== FALSE) {
    $allowed = user_access('administer masquerade') ||
                     db_select('masquerade_users', 'm')
      ->fields('m', array('uid_to'))
      ->condition('m.uid_to', $to_uid, '=')
      ->condition('m.uid_from', $user->uid, '=')
      ->execute()
      ->fetchField();
  }
  if (isset($_SESSION['masquerading'])) {
    form_set_error('masquerade_user_field', t('You are already masquerading. Please <a href="@unswitch">switch back</a> to your account to masquerade as another user.', array('@unswitch' => url('masquerade/unswitch', array('query' => array('token' => drupal_get_token('masquerade/unswitch')))))));
  }

If you don't like using the 'adminiser masquerade' permission for this, you could create a 'masquerade as any user' or simply test for uid == 1.

I don't understand the current purpose of the auto-complete if it is validated against the list. Why wouldn't the user just click the link rather than type?

EDIT: And further, why auto-complete to an arbitrary user if you aren't going to allow that user?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

DanChadwick’s picture

Issue summary: View changes
mrmikedewolf’s picture

I second this request. I've created a patch that adds a new permission, "Masquerade as any user" allowing those with it to masquerade freely as they could before.

jemond’s picture

This is especially useful on sites where you have a thousands of users, and adding them all to a masquerade list isn't efficient.

DanChadwick’s picture

I have applied #2. Thank you.

I have carefully read the code in #2, as well as in commit 79e5e5 which implemented the security change for RC6. Studying it carefully, I could find no problems.

I then applied the patch, set the masquerade as any user for the administrator role. Using the admin account, I could use the auto-complete form in the block and the links on the target users' profile page to masquerade.

I then logged in as a non-admin user and confirmed that I could no longer do either, as desired and as in accord with RC6.

I observed only two minor things:

1) The indentation of the db_select would be better as follows:

  if ($to_uid !== FALSE) {
    $allowed = user_access('masquerade as any user') ||
               db_select('masquerade_users', 'm')
                  ->fields('m', array('uid_to'))
                  ->condition('m.uid_to', $to_uid, '=')
                  ->condition('m.uid_from', $user->uid, '=')
                  ->execute()
                  ->fetchField();
  }

2) The permission is not initially set for the Administrator role, as is the custom. This could be done in an update routine. Or it could be argued that in light of the RC6 security release, it is best left as a strictly opt-in feature.

I leave 1) to the maintainer to format to his/her preference. I leave 2) as it on the theory it is the most conservative approach.

Maybe someone else can test this too and then we can mark it RTBC.

DanChadwick’s picture

Status: Active » Needs review

Status: Needs review » Needs work

The last submitted patch, 2: masquerade_new-permissions-2211547-2.patch, failed testing.

DanChadwick’s picture

Test failing are unrelated to this patch. RC6 will fail as well.

The tests, unchanged by this patch, create a user with permissions administer site configuration, administer permissions, and masquerade as user. It then tries to masquerade and fails because it can't (and then can't switch back).

It is is desired to fix these tests, the user should be created with the masquerade as any user permission. It would also be wise to test that it can't masquerade when it doesn't have this permission.

titouille’s picture

And a same fix for the 6.x version ? because problem is the same... A new permission would be added to "masquerade as any user" for users with correct role...

shrop’s picture

I would think the same issue would exist in 6.x. Let's get some patches ironed out for both 6.x and 7.x, test them, and I can get them in there.

Thanks for all the work on this so far folks!

joegraduate’s picture

Status: Needs work » Reviewed & tested by the community

I have tested the patch in #2 and have verified that the new 'masquerade as any user' permission restores the desired (former) functionality and that the security fixes implemented yesterday are still functioning.

DanChadwick’s picture

Status: Reviewed & tested by the community » Needs work
FileSize
4.8 KB

The attached patch is a straight re-roll of mrmikedewolf's fine (RTBC) patch, with the indentation change that I mentioned, plus extensively updated tests.

The previous tests were completely out-of-date. RC6 would not pass a single one. These tests are now:

  • Create the admin user with sufficient privileges to execute the tests.
  • Validate that the masquerade configuration page is actually reached.
  • Validate that the masquerade block can be enabled.
  • Validate that the administrator can masquerade using the user profile page.
  • Validate that switch back works.
  • Validate that the Masquerade block can switch using the text field.

The tests did not work because a) not enough privileges (even for RC6) b) text messages for successful masquerade and switch back changed, and c) masquerade links now have tokens.

I am leaving this RTBC, but it would be wise to ensure that testbot likes these tests. They ran successfully on my development machine.

Thank you for your work on this module. I find it indispensable.

DanChadwick’s picture

Status: Needs work » Reviewed & tested by the community
deekayen’s picture

I pushed #11 so others can at least grab a -dev build soon.

David_Rothstein’s picture

@@ -28,6 +28,10 @@ function masquerade_permission() {
       'title' => t('Masquerade as user'),
       'description' => t('Masquerade as another user.'),
     ),
+    'masquerade as any user' => array(
+      'title' => t('Masquerade as any User'),
+      'description' => t('Masquerade as any user.'),
+    ),

I think this entry should really have 'restrict access' => TRUE added to it. Because it's basically a permission that (by design) allows the security fix to be bypassed.

David_Rothstein’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
446 bytes

Didn't notice that the original patch has been committed when I wrote that. Here's a followup patch.

Status: Needs review » Needs work

The last submitted patch, 15: masquerade-any-user-followup-2211547-15.patch, failed testing.

David_Rothstein’s picture

Status: Needs work » Needs review

Hm, patch definitely applies for me.

David_Rothstein’s picture

Status: Needs review » Needs work

The last submitted patch, 15: masquerade-any-user-followup-2211547-15.patch, failed testing.

kwfinken’s picture

This is definitely a needed patch. Adding a new permission is great. We cannot allow it to be just based on user 1 would not work because our organization has multiple administrators, each with their own account.

srees’s picture

Plus one on comment #8...

I don't have time to write it today, but if v6 is still hung out to dry Monday, I'll write the patch then.

**edit** nevermind, went ahead and punched out a duplicate of #11's patch for D6, sans testing. See https://drupal.org/comment/8552435#comment-8552435

DanChadwick’s picture

@David_Rothstein - Definitely on the 'restrict access'. I would also set that for 'masquerade as admin'. If you can masquerade as admin, you can set anything.

deekayen’s picture

I pushed #15.

DanChadwick’s picture

@deekayen - I suggest you add the same 'restrict access' to 'masquerade as admin' for both safety and consistency.

deekayen’s picture

Pushed #24.

DanChadwick’s picture

Status: Needs work » Fixed

Status: Fixed » Closed (fixed)

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

xaa’s picture

still not commit in the rc7?

potassiumchloride’s picture

I'm having this same problem with rc7.

RaulMuroc’s picture

Status: Closed (fixed) » Active

Problem persists in latest rc7 version.

stewart.adam’s picture

I'm seeing this error appear when attempting to masquerade as a user that doesn't exist. I can masquerade as any user, but did have to adjust the permission as it seems to have been unchecked (perhaps due to a rename?) at some point during an upgrade.

liquid06’s picture

Just skimming through this issue, it's easy to miss: rc7 adds a new permission - Masquerade as any user - that is not enabled for any roles by default.

Allowing that for the administrator role would allow admins to masquerade as any user by selecting their username via the autocomplete widget. Typing a username that doesn't exist into the autocomplete widget results in "You are not allowed to masquerade as the selected user."