Permitir que o usuário faça qualquer coisa em seu próprio esquema, mas não crie ou elimine o próprio esquema

Eu criei um esquema no SQL Azure e concedi as seguintes permissões a uma função de banco de dados:

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;

Através das permissões definidas acima, é myuserpossível criar / soltar seu próprio esquema, para superar o problema, tentei a permissão ALTER ANY SCHEMA. Mas essa permissão também nega que o usuário crie / descarte tabelas.

Quais permissões são necessárias para permitir que o usuário faça algo dentro de seu próprio esquema, mas não possa criar ou descartar o próprio esquema?

Não há necessidade de conceder CONTROLno esquema.
A permissão necessária DROP SCHEMAestá CONTROLno esquema ou ALTER ANY SCHEMAno nível do banco de dados, e é por isso que o usuário conseguiu descartar o esquema. A remoção dessas duas permissões impedirá que os usuários associados à função criem e descartem o esquema (a menos que tenham permissões de nível superior, é claro).

A permissão necessária para CREATE ALTERe DROPoutros objetos é a CREATEpermissão para o tipo de objeto (tabela \ procedure \ function \ view) combinado com a ALTERpermissão no esquema.
Você já tem essas permissões em seu script; portanto, tudo o que você precisa fazer é remover a CONTROLpermissão. Para referência, aqui está uma lista BOL de DDLinstruções em que Você pode encontrar a permissão necessária para todos os tipos de objetos.

Para os preguiçosos, eis o seu código após remover a permissão desnecessária:

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;

Observe que, como o novo esquema possui a autorização "dbo", o usuário poderá acessar indiretamente todos os objetos de banco de dados nos quais o esquema pertence ao dbo.

Exemplo:

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 é a operação correta do mecanismo do SQL Server; permissões permeiam em outros esquemas com a mesma autorização. Para restringir esse acesso, aqui está uma opção para a criação do esquema:

CREATE SCHEMA myschema AUTHORIZATION myrole;