Restrict migrate upgrade permission to user1

Well it is not just web test - if the migration is preserving IDs and a user is logged in as a user that will be migrated all sorts of weird things can happen.

I think it would make sense to restrict this permission to user 1. As @mikeryan pointed out, it doesn't make sense to have data like a user account in the destination site before migration anyway.

@alexpott and I discussed whether it should also have a settings.php override flag, but agreed that would not work from a security standpoint.

Why wouldn't the settings.php override work from a security standpoint? Doesn't really seem worse than the update.php one, or leaving the installer open on an uninstalled site etc.

I have a knee-jerk reaction against requiring user 1 only, since we've got various issues open to try to discourage people from logging in as user/1. Although I get why we can't let other users migrate when the migration is supposed to destroy their account potentially.

@catch because update_free_access does not require you to be anonymous. So you could be another user and then this is overwritten by the incoming migration and you are suddenly logged in as a user you should not be able to log in as.

We could make the access check (user 1 || (anonymous && $migrate_free_access) though to avoid that.

This is fixing a bug - if you are logged in as user which does not have administer software updates in the source site the migration will break.

Gonna re-upload the patch and see if that helps...

Missing an @group from the test - fun...

Since the Migrate UI is alpha-experimental and new as of 8.1.x, this and other issues for it can be committed during the 8.1.x beta.

I don't think having a $migrate_free_access is a good idea, for the reasons @alexpott describes, but also the risk of someone leaving a site open to migrate anything attackers want into it seems pretty... well, not worth risking. For update.php, you already need access to the codebase to change things. And for migrate it's not just an uninstalled site; it'd be easy to leave it on accidentally post-migration.

If the access check is only checking if we're user 1 is it worth having a generic, SuperUser access check rather than migrate specific? Although I would agree, we don't want to encourage people using it as it wouldn't normally be needed.

@benjy I think we don't want to encourage people to use it. Doing something like this on a case by case is acceptable.

Patch looks good to me.

Unrelated test failure :(

Yes agreed on keeping the user 1 access to a one-off, don't want to make that easy and this is a very particular case.

Committed/pushed to 8.2.x and cherry-picked to 8.1.x. Thanks!