Permitir al usuario hacer cualquier cosa dentro de su propio esquema pero no crear o soltar el esquema en sí

Creé un esquema en SQL Azure y otorgué los siguientes permisos a un rol de base de datos:

CREATE ROLE myrole AUTHORIZATION dbo;
EXEC sp_addrolemember 'myrole', 'myuser';

CREATE SCHEMA myschema AUTHORIZATION dbo;

GRANT ALTER, CONTROL, DELETE, EXECUTE, INSERT, REFERENCES, SELECT, UPDATE, VIEW 
DEFINITION ON SCHEMA::myschema TO myrole;

GRANT CREATE TABLE, CREATE PROCEDURE, CREATE FUNCTION, CREATE VIEW TO myrole;

A través de los permisos definidos anteriormente myuserpuede crear / eliminar su propio esquema, por lo que para superar el problema probé el permiso ALTERAR CUALQUIER ESQUEMA. Pero este permiso también niega al usuario crear / soltar tablas.

¿Qué permisos son necesarios para permitir que el usuario haga algo dentro de su propio esquema pero no pueda crear o descartar el esquema en sí?

No hay necesidad de otorgar CONTROLen el esquema.
El permiso requerido DROP SCHEMAestá CONTROLen el esquema o ALTER ANY SCHEMAen el nivel de la base de datos, y es por eso que su usuario pudo eliminar el esquema. Eliminar estos dos permisos evitará que los usuarios asociados a roles creen y descarten el esquema (a menos que tengan permisos de nivel superior, por supuesto).

El permiso requerido para CREATE ALTERy DROPotros objetos es el CREATEpermiso para el tipo de objeto (tabla \ procedimiento \ función \ vista) combinado con ALTERpermiso en el esquema.
Ya tiene estos permisos en su secuencia de comandos, por lo que todo lo que tiene que hacer es eliminar el CONTROLpermiso. Como referencia, aquí hay una lista BOL de DDLdeclaraciones donde puede encontrar el permiso requerido para todos los tipos de objetos.

Para los perezosos, aquí está su código después de eliminar los permisos innecesarios:

CREATE ROLE myrole AUTHORIZATION dbo;
EXEC sp_addrolemember 'myrole', 'myuser';

CREATE SCHEMA myschema AUTHORIZATION dbo;

GRANT ALTER, DELETE, EXECUTE, INSERT, REFERENCES, SELECT,
          UPDATE, VIEW DEFINITION ON SCHEMA::myschema TO myrole;

GRANT CREATE TABLE, CREATE PROCEDURE, CREATE FUNCTION, CREATE VIEW TO myrole;

Tenga en cuenta que dado que el nuevo esquema tiene la autorización de "dbo", el usuario podrá acceder indirectamente a todos los objetos de la base de datos donde dbo posee el esquema.

Ejemplo:

select * from dbo.test; --fails

create view myschema.test
as 
select * 
from dbo.test; --view is created

select * from myschema.test;  --contents of dbo.test now revealed.

Esta es la operación correcta del motor de SQL Server; Los permisos penetran en otros esquemas con la misma autorización. Para restringir dicho acceso, aquí hay una opción para la creación del esquema:

CREATE SCHEMA myschema AUTHORIZATION myrole;