It appears the
ALTER permission granted at the database level allows the principal to which it is granted, to create security principals in the database.
Consider the below example:
/* setup database */
CREATE DATABASE MyNewDB
/* create a login and user and then grant ALTER permissions */
CREATE LOGIN MyLogin WITH PASSWORD = 'My57r0ngp455w0rd'
CREATE USER MyUser FOR LOGIN MyLogin
GRANT ALTER TO MyUser
/* running as our new user which only has ALTER permissions, create a user and a role */
EXECUTE AS LOGIN = 'MyLogin'
CREATE USER UserCreatedByMyLogin FOR LOGIN SomeOtherLogin
CREATE ROLE RoleCreatedByMyLogin
ALTER ROLE RoleCreatedByMyLogin ADD MEMBER UserCreatedByMyLogin
/* verify success */
WHERE role_principal_id = USER_ID('RoleCreatedByMyLogin') AND
member_principal_id = USER_ID('UserCreatedByMyLogin')
The user MyUser is able to create a user, a role and then add the user to the role, with only ALTER permissions.
The documentation for ALTER states
Confers the ability to change the properties, except ownership, of a particular securable. When granted on a scope, ALTER also bestows the ability to alter, create, or drop any securable that is contained within that scope. For example, ALTER permission on a schema includes the ability to create, alter, and drop objects from the schema.
Requires ALTER ANY USER permission on the database.
Requires CREATE ROLE permission on the database or membership in the db_securityadmin fixed database role.
so none of the documentation appears to outline the behavior I am seeing above. Is this a bug, or am I missing something?