az role assignment create scope default to subscription if empty

[yungezz]

az feedback auto-generates most of the information requested below, as of CLI version 2.0.62

Describe the bug
A clear and concise description of what the bug is.

Summary

Using azure-cli (in actual version of 2.0.79) and az role assignment create command.

The problem I see is the use of --scope parameter.
Empty (I mean empty = specified but undefined parameter) scope equals to default (therefore subscription) scope.

Why is that? How about the error message for this action? User is not aware of the issue and scope automatically applies on the subscription.
That can be harmful in some cases (see examples below) - user or service principal can be assigned more powerfull scope and you can imagine the consequences.

Description

Following examples can cause elevation of privileges. In case of resource name typo, non-existing resource, etc...

Steps to Reproduce:

# login to the portal
az login
# obtain assignee identifier (user in this case)
ASSIGNEE=$(az account show --query 'user.name' -o tsv)

# acceptable version: undefined scope => default scope => applied to subscription, OK
az role assignment create \
--assignee "${ASSIGNEE}" \
--role Contributor

# Why empty (empty, not undefined!) scope equals to default scope? Following examples can cause elevation of privileges.

# version 1: EMPTY scope => applied to subscription (nonintended elevation of privileges)
az role assignment create \
--assignee "${ASSIGNEE}" \
--scope "" \
--role Contributor

# version 2: non existing resource => EMPTY scope => applied to subscription (nonintended elevation of privileges)
az role assignment create \
--assignee "${ASSIGNEE}" \
--scope "$(az storage account show --name iMakeATypoInName --subscription ${AZURE_SUBSCRIPTION} --query 'id' -o tsv)" \
--role Contributor

# version 3: non existing resource in different way => EMPTY scope => applied to subscription (nonintended elevation of privileges)
OBJECT=$(az storage account show --name iMakeATypoInName --subscription ${AZURE_SUBSCRIPTION} --query 'id' -o tsv)
az role assignment create \
--assignee "${ASSIGNEE}" \
--scope "${OBJECT}" \
--role Contributor

# check for all the three versions:
az role assignment list --assignee "${ASSIGNEE}"

# output:
[
{
"canDelegate": null,
"id": "/subscriptions/<subscription_guid>/providers/Microsoft.Authorization/roleAssignments/<assignment_guid>",
"name": "<assignment_guid>",
"principalId": "<principal_id>",
"principalName": "andrej.zelnik@....",
"principalType": "User",
"roleDefinitionId": "/subscriptions/<subscription_guid>/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c",
"roleDefinitionName": "Contributor",
"scope": "/subscriptions/<subscription_guid>",
"type": "Microsoft.Authorization/roleAssignments"
}
]

Supporting materials/ references:

• https://docs.microsoft.com/en-us/cli/azure/role/assignment?view=azure-cli-latest#az-role-assignment-create

To Reproduce
Steps to reproduce the behavior.

Expected behavior
A clear and concise description of what you expected to happen.

Environment summary
Install Method (e.g. pip, interactive script, apt-get, Docker, MSI, edge build) / CLI version (az --version) / OS version / Shell Type (e.g. bash, cmd.exe, Bash on Windows)

Additional context
Add any other context about the problem here.

[jsntcy]

@arrownj, @jiasli, please take a look, thanks.