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?
Comment | File | Size | Author |
---|---|---|---|
#15 | masquerade-any-user-followup-2211547-15.patch | 446 bytes | David_Rothstein |
#11 | masquerade-masquerade_as_any_user_with_tests-2211547-11.patch | 4.8 KB | DanChadwick |
#2 | masquerade_new-permissions-2211547-2.patch | 1.76 KB | mrmikedewolf |
Comments
Comment #1
DanChadwick CreditAttribution: DanChadwick commentedComment #2
mrmikedewolf CreditAttribution: mrmikedewolf commentedI 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.
Comment #3
jemond CreditAttribution: jemond commentedThis is especially useful on sites where you have a thousands of users, and adding them all to a masquerade list isn't efficient.
Comment #4
DanChadwick CreditAttribution: DanChadwick commentedI 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:
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.
Comment #5
DanChadwick CreditAttribution: DanChadwick commentedComment #7
DanChadwick CreditAttribution: DanChadwick commentedTest 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.
Comment #8
titouilleAnd 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...
Comment #9
shrop CreditAttribution: shrop commentedI 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!
Comment #10
joegraduateI 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.
Comment #11
DanChadwick CreditAttribution: DanChadwick commentedThe 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:
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.
Comment #12
DanChadwick CreditAttribution: DanChadwick commentedComment #13
deekayen CreditAttribution: deekayen commentedI pushed #11 so others can at least grab a -dev build soon.
Comment #14
David_Rothstein CreditAttribution: David_Rothstein commentedI 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.Comment #15
David_Rothstein CreditAttribution: David_Rothstein commentedDidn't notice that the original patch has been committed when I wrote that. Here's a followup patch.
Comment #17
David_Rothstein CreditAttribution: David_Rothstein commentedHm, patch definitely applies for me.
Comment #18
David_Rothstein CreditAttribution: David_Rothstein commented15: masquerade-any-user-followup-2211547-15.patch queued for re-testing.
Comment #20
kwfinken CreditAttribution: kwfinken commentedThis 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.
Comment #21
srees CreditAttribution: srees commentedPlus 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
Comment #22
DanChadwick CreditAttribution: DanChadwick commented@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.
Comment #23
deekayen CreditAttribution: deekayen commentedI pushed #15.
Comment #24
DanChadwick CreditAttribution: DanChadwick commented@deekayen - I suggest you add the same 'restrict access' to 'masquerade as admin' for both safety and consistency.
Comment #25
deekayen CreditAttribution: deekayen commentedPushed #24.
Comment #26
DanChadwick CreditAttribution: DanChadwick commentedComment #28
xaa CreditAttribution: xaa commentedstill not commit in the rc7?
Comment #29
potassiumchloride CreditAttribution: potassiumchloride commentedI'm having this same problem with rc7.
Comment #30
RaulMuroc CreditAttribution: RaulMuroc commentedProblem persists in latest rc7 version.
Comment #31
stewart.adam CreditAttribution: stewart.adam commentedI'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.
Comment #32
liquid06 CreditAttribution: liquid06 commentedJust 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."